- crux-devel - lists.crux.nu

CVE-2015-4000 ("Logjam") -- Update ISO
by James Mills 22 Jun '15

22 Jun '15

This is mostly to Matt; Can we get the ISO rebuilt and updated for this CVE? I'm finding it *harder* lately to keep up with IRC so I may have missed anything said or not said about this :) cheers James James Mills / prologic E: prologic(a)shortcircuit.net.au W: prologic.shortcircuit.net.au

1 0

Adding a "recompile" meta field to Pkgfiles
by Leo Unglaub 03 Jan '15

03 Jan '15

Hey guys, i want to propose a "recompile" meta field in Pkgfiles that would list packages that need to be rebuild after an update of the current package. This would be very handy specially for the XFCE4 ports with i would love to take over and maintain. But thats another topic ;) What are your thoughts on that one? An example would look like that: > # Description: PolarSSL - Straightforward, Secure Communication > # URL: https://polarssl.org/ > # Maintainer: Leo Unglaub, leo at leo-unglaub dot net > # Developer: Paul Bakker, p.j.bakker at offspark dot com > # Depends on: cmake > # Recompile: hiawatha Greetings Leo -- Leo Unglaub Website: https://www.leo-unglaub.net Twitter: https://twitter.com/LeoUnglaub

5 7

Dropping some unused ports in contrib
by Matt Housh 07 Nov '13

07 Nov '13

Greetings, all, Just wanted to let the list know that I plan to drop the following from contrib as I no longer use them: bridge-utils faac faad2 guile nwn-diamond quake4 teamspeak2-client unace If anyone would like to take any of them, feel free. Otherwise I'll remove them sometime in the near future. Regards, Matt

1 0

prt-get --group
by Alan Mizrahi 30 Aug '13

30 Aug '13

Hi people, I made a change in prt-get to add a --group parameter. When --group is present the operation becomes a group operation, and a failure to install or upgrade a package makes prt-get stop. So: prt-get grpinst ... Becomes: prt-get install --group ... But one can also use it with the other invocations: prt-get update --group ... prt-get depinst --group ... prt-get sysup --group This renders grpinst obsolete, so the patch also removes it. Any opinions? Best regards, Alan Mizrahi

2 1

[oeriksson@mandriva.com: [oss-security] CVE Request -- php - handling of certs with null bytes]
by Fredrik Rinnestam 16 Aug '13

16 Aug '13

----- Forwarded message from Oden Eriksson <oeriksson(a)mandriva.com> ----- Date: Wed, 14 Aug 2013 10:47:06 +0200 From: Oden Eriksson <oeriksson(a)mandriva.com> To: oss-security(a)lists.openwall.com Subject: [oss-security] CVE Request -- php - handling of certs with null bytes User-Agent: KMail/4.10.5 (Linux/3.8.13.4-desktop-1.mga3; KDE/4.10.5; x86_64; ; ) Hello, A similar flaw as in ruby and python was discovered and fixed for php. ruby - CVE-2013-4073 python - CVE-2013-4238 php - CVE-2013-???? http://www.ruby-lang.org/en/news/2013/06/27/hostname-check-bypassing-vulner… Upstream fixes: http://git.php.net/?p=php-src.git;a=commit;h=dcea4ec698dcae39b7bba6f6aa0893… http://git.php.net/?p=php-src.git;a=commit;h=2874696a5a8d46639d261571f915c4… _https://bugs.mageia.org/show_bug.cgi?id=10997_ Cheers. -------- [1] http://www.ruby-lang.org/en/news/2013/06/27/hostname-check-bypassing-vulner… [2] http://git.php.net/?p=php-src.git;a=commit;h=dcea4ec698dcae39b7bba6f6aa0893… [3] http://git.php.net/?p=php-src.git;a=commit;h=2874696a5a8d46639d261571f915c4… ----- End forwarded message ----- -- Fredrik Rinnestam -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

2 1

opt access application
by Emmanuel Benisty 01 Apr '13

01 Apr '13

Hi everyone, Some kind of chain reaction (involving Swedes, IRC and smileys) triggered this application for opt access. Even if I never really had an official user repository, I have always been willing to give back what I could to CRUX community. Being officially involved in the project would definitely be the most efficient way to do so. Therefore, I'm pleased to submit this application for your consideration. Thanks+cheers, -- Emmanuel (horrorStruck)

8 12

[jlieskov@redhat.com: [oss-security] CVE Request -- glibc: Integer overflows, leading to stack-based buffer overflows in strto* related routines]
by Fredrik Rinnestam 13 Aug '12

13 Aug '12

----- Forwarded message from Jan Lieskovsky <jlieskov(a)redhat.com> ----- Date: Mon, 13 Aug 2012 06:52:23 -0400 (EDT) From: Jan Lieskovsky <jlieskov(a)redhat.com> To: "Steven M. Christey" <coley(a)linus.mitre.org> Cc: oss-security(a)lists.openwall.com, "Joseph S. Myers" <joseph(a)codesourcery.com>, Jeff Law <law(a)redhat.com> Subject: [oss-security] CVE Request -- glibc: Integer overflows, leading to stack-based buffer overflows in strto* related routines X-Mailer: Zimbra 7.2.0_GA_2669 (ZimbraWebClient - FF3.0 (Linux)/7.2.0_GA_2669) Hello Kurt, Steve, vendors, multiple integer overflows, leading to stack-based buffer overflows were found in various stdlib functions of GNU libc (strtod, strtof, strtold, strtod_l and related routines). If an application, using the affected stdlib functions, did not perform user-level sanitization of provided inputs, a local attacker could use this flaw to cause such an application to crash or, potentially, execute arbitrary code with the privileges of the user running the application. Upstream bug report: [1] http://sourceware.org/bugzilla/show_bug.cgi?id=14459 Upstream patch (might not be the final one): [2] http://sourceware.org/ml/libc-alpha/2012-08/msg00202.html References: [3] https://bugzilla.redhat.com/show_bug.cgi?id=847715 Could you allocate a CVE id for this? Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Response Team ----- End forwarded message ----- -- Fredrik Rinnestam

1 0

CRUX next II
by Juergen Daubert 27 Jul '12

27 Jul '12

Hi all, first a big thanks for all the replies we got for the initial 'CRUX next' thread [1]. We like to summarize the results a bit and do the following proposal: - we switch our main development platform to the x86_64 architecture. This will be called CRUX 3.0 and will be the only version with official support. We go for the "multilib ready" approach, meaning that our toolchain is capable to produce 32-bit binaries. Besides glibc-32 we will not ship any 32-bit compat library on our ISO. We will merge everything needed for the above into our main repos and add _one_ additional repo, called compat-32, for the 32-bit compatibility libraries. After all we will have 4 official repos: core, opt, xorg and compat-32. - to give our users a smooth option to switch to x86_64 we create a final i686 version, called CRUX 2.8. It includes the latest toolchain and roughly all the stuff listed on [2]. If we find volunteers for it, we might create another repo, probably called i686, as _one_ i686 overlay for the main repositories. A summary timeline for the above should look something like this: 1. create a branch 2.8 based on 2.7 for the core/opt/xorg repos 2. update the toolchain and do verything described in [2] 3. release CRUX 2.8 for the i686 architecture 4. create a branch 3.0 based on 2.8 for the core/opt/xorg repos and add the compat-32 repository 5. merge everything from *-x86_64.git and *-multilib.git into our {core,opt,xorg,compat-32}.git repositories 6. release CRUX 3.0 for the x86_64 architecture best regards Matt + Juergen [1] http://thread.gmane.org/gmane.linux.distributions.crux.devel/2291 [2] http://crux.nu/Wiki/TODO28

1 0

CRUX next
by Juergen Daubert 14 Jul '12

14 Jul '12

Hello, now that glibc 2.16 is available a new version of CRUX seems to be doable. But before we start working, we should consider some important, upcoming changes besides the usual small updates and improvements [1]. a) Switch our main development platform to the x86_64 architecture [2], the first version should be called CRUX 3.0. At the time Per Liden had created CRUX, the i686 processor on base of the 32-bit Intel IA-32 architecture was state of the art and therefore chosen by him as the default optimization for CRUX. But nowadays, over 10 years later [2], the i686 arch is more or less obsolete, at least for desktop machines. The 64-bit extension to the x86 instruction set, mostly called x86_64, is the the new standard now. We had extensive discussions on IRC about the type of system we want, a pure 64-bit or a multilib system. The main consensus is that we ship a "multilib ready" system, but without the 32-bit compatibility libraries except for glibc-32. The reason for this exceptions is the gcc compiler, which needs the glibc-32 at build- but not at run-time. b) Keep our repository layout as simple as possible At the moment we have official repos for i686 and overlay repos for x86_64 and multilib on top of those. That's ok and the best way to do it at the moment, but not really neat for the final solution. I'd suggest to merge everything needed by a) into our core/opt/xorg repos and add only _one_ additional repo, probably called 'lib32', for the compatibility libraries. c) Create a final CRUX 2.7.2 for i686 TBH I'm unsure if we should do that, but it would be a nice service for all people using CRUX on older hardware and might be the basis for contributed i686 ISOs in the future. IMO updated xorg stuff is a must-have for such a version, however, as the version number 2.7.2 suggests, I wouldn't change the toolchain. The main idea behind is to have a final mostly up-to-date system with a very solid toolchain for the 'old' architecture. d) Device management As outlined in another mail [4], the udev sources has been merged into systemd and it's no longer possible to build a standalone udev with minimal dependencies. It is foreseeable that systemd will become a hard dependency for udev soon. What can we do? - stick with udev 182 or try to extract newer versions from systemd even if we had to add stuff like dbus and intltools to our core ports. How long will this work? - switch our init system to systemd - use devtmpfs together with mdev for device managment IMO going with mdev is the most clear and CRUX-ish way [5], but we might run in greater problems in the future, because more stuff will depend on udev/systemd. This is especially true for all kind of "desktop" software and everything that depends on dbus, *kit and the like. What do you think? best regards Juergen [1] http://crux.nu/Wiki/TODO28 [2] One may ask why not doing both alongside, but that is too much work for our little team, at least as a official version. [3] http://crux.nu/Main/History [4] http://article.gmane.org/gmane.linux.distributions.crux.devel/2284 [5] From my personal point of view I was never really happy with udev. The whole development is unpredictable and udev is doing all kind of "magic" behind my back.

6 12

Kind of a quiet list
by Don Cupp 02 Jul '12

02 Jul '12

For as awesome as crux is, I thought the list would be a lot busier. Best, Don Cupp

2 1