March 2016 - CRUX - lists.crux.nu

Easier patching with pkgmk
by Willy Goiffon 26 May '16

26 May '16

Hi everyone, I had an idea to make software patching easier, and lower the need to fork ports. Sometimes, I just fork some port from contrib because I want to add a patch (eg: thttpd), or I need to modify a file before actually compiling the software (eg: config.h on contrib/st). I figured out that by adding a single variable to `/etc/pkgmk.conf`, it would be easier to "tweak" sofwares by patching them beforehand: ``` /etc/pkgmk.conf [...] PKGMK_PATCH_DIR=/usr/patch And then, have ports include something like: ``` /usr/port/contrib/example/PKgfile [...] cd $name-$version cat $PKGMK_PATCH_DIR/$name/*.diff | patch -Np1 make make DESTDIR=$PKG PREFIX=/usr MANDIR=/usr/man install So if I need a patch for thttpd, I'll just add it to `/usr/patch/thttpd`. To have the `st` port configured with my `config.h`, I'll just create a patch for it in `/usr/patch/st`. All ports might not need this obviously, but this could result in a simple and efficient way to let user tweak packages from the "official" port trees without any need to actually fork them, and double the effort. What do you think about it? -- Willy Goiffon (z3bra on #crux)

5 6

repos providing only md5 sums
by rain1＠openmailbox.org 01 Apr '16

01 Apr '16

Hello, I noticed that crux mirrors only provide md5 hashes for verification. I recommend moving to sha256 which is a secure hash function. md5 is not a secure hash function any longer as it has several weaknesses that are not expected of a hash [1]. There are a couple instances of it being exploited in serious situations in the real world, for example [2] and [3]. Collisions can be forged on a home computer today [4]. These sort of attacks do not directly affect the way the hash is used in crux but they do demonstrate weakness in md5. I think this gives a strong case for depreciating its usage. There was a bug report about this 8 years ago which was closed <https://crux.nu/bugs/index.php?do=details&task_id=223>. If people agree in this thread then maybe that bug report could be re-opened. Thank you * [1] https://www.kb.cert.org/vuls/id/836068 * [2] https://www.win.tue.nl/hashclash/rogue-ca/ * [3] https://www.trailofbits.com/resources/flame-md5.pdf * [4] http://natmchugh.blogspot.co.uk/2014/10/how-i-created-two-images-with-same-…

9 16

Re: repos providing only md5 sums
by Thomas Penteker 31 Mar '16

31 Mar '16

Hello, I forked exactly that repo and _really_ pulled everything from upstream. Chneukirchen hasnt. There is also a commit fixing a fixed path problem I wanted to have implemented mor elegantly. Regards, Thomas -------- Ursprüngliche Nachricht -------- Von: rain1(a)openmailbox.org Datum: 31.03.2016 17:35 (GMT+01:00) An: John Vogel <jvogel4(a)stny.rr.com> Cc: crux(a)lists.crux.nu Betreff: Re: repos providing only md5 sums On 2016-03-31 13:46, John Vogel wrote: > On Mon, 28 Mar 2016 21:30:23 -0400 > Ryan Mullen <rmmullen(a)gmail.com> wrote: > >> A few questions: >> >> 1. Signify currently produces a build warning about an implicit >> declaration >> of function 'getentropy.' Am I missing something? Surely the crux fork >> is >> not the only portable fork of signify - what are we doing in ours >> that's >> special and requires a custom fork? >> > > https://github.com/chneukirchen/signify > > I haven't tested it yet, but I've had good luck with his cwm port in > the past. > > Cheers, > John > _______________________________________________ > CRUX mailing list > CRUX(a)lists.crux.nu > https://lists.crux.nu/mailman/listinfo/crux There are a lot of ports of signify to linux (also a reimplementation in Go and a 'mini' version): * https://github.com/aperezdc/signify * https://github.com/vstakhov/asignify * https://github.com/ebfe/signify * https://github.com/chneukirchen/signify * https://github.com/Blitznote/signify * https://github.com/nurse/signify * https://github.com/vstakhov/asignify * https://github.com/stoeckmann/signify-windows * https://www.fefe.de/signify/ * https://jedisct1.github.io/minisign/ Distros seem to have (unofficial) packages that point to aperezdc's version: * https://aur.archlinux.org/packages/signify/ * https://packages.debian.org/source/sid/signify-openbsd * https://gpo.zugaina.org/app-crypt/signify The version by chneukirchen looks good - especially because it was pulling in all the new changes from upstream, aperezdc did not seem to do that? - although he just recently marked it as unmaintained and is now: * https://github.com/chneukirchen/outils The situation is still not ideal but using outils seems like a fine idea for now. _______________________________________________ CRUX mailing list CRUX(a)lists.crux.nu https://lists.crux.nu/mailman/listinfo/crux

1 0

libbluray: source fetching via wget
by John Vogel 31 Mar '16

31 Mar '16

After seeing the recent commit for libbluray about hosting the source, I was curious to see if this was a wget bug. I got a hit when doing a web search (1). I'm not certian if it's a bug or not, but the info from the link bore out: curl has no problems with this source address; and, if the source address is changed from ftp://ftp... to http://ftp... , then wget fetches the tarball just fine. 1) http://comments.gmane.org/gmane.linux.slackware.slackbuilds.user/13108 Cheers, John

3 4

crux website
by Torsten Henschel 30 Mar '16

30 Mar '16

Hey, currently is no detailed information on crux release 3.2. The wiki timeline looks somehow bad. https://crux.nu/Main/Timeline greetings

2 1

ports/opt (3.2): [notify] jdk: security update to 1.8.0_77 fixes CVE-2016-0636
by crux＠crux.nu 26 Mar '16

26 Mar '16

commit 878b7b38f6d779f6864a7dedb22ff6f694b85804 Author: Danny Rawlins <monster.romster(a)gmail.com> Date: Sat Mar 26 14:57:41 2016 +1100 [notify] jdk: security update to 1.8.0_77 fixes CVE-2016-0636 http://www.oracle.com/technetwork/java/javase/8u77-relnotes-2944725.html diff --git a/jdk/.md5sum b/jdk/.md5sum index 875a192..e04565d 100644 --- a/jdk/.md5sum +++ b/jdk/.md5sum @@ -1 +1 @@ -4928d67633c5e5b397315b5cf5f8fa2e jdk-8u74-linux-x64.tar.gz +ee501bef73ba7fac255f0593e595d8eb jdk-8u77-linux-x64.tar.gz diff --git a/jdk/Pkgfile b/jdk/Pkgfile index 159d713..f7fa910 100644 --- a/jdk/Pkgfile +++ b/jdk/Pkgfile @@ -4,7 +4,7 @@ # Packager: Simone Rota, sip at crux dot nu name=jdk -version=1.8.0_74 +version=1.8.0_77 release=1 source=(file:///$name-8u${version##*_}-linux-x64.tar.gz)

1 0

ports/opt (3.2): [notify] jre: security update to 1.8.0_77
by crux＠crux.nu 25 Mar '16

25 Mar '16

commit 39491c20294c2feaea171b64be8c7ca75d2a056c Author: Juergen Daubert <jue(a)jue.li> Date: Fri Mar 25 12:22:54 2016 +0100 [notify] jre: security update to 1.8.0_77 http://www.oracle.com/technetwork/java/javase/8u77-relnotes-2944725.html diff --git a/jre/.md5sum b/jre/.md5sum index 6acc54b..c020362 100644 --- a/jre/.md5sum +++ b/jre/.md5sum @@ -1 +1 @@ -60b85f47a0456a01c970b2298adb925a jre-8u74-linux-x64.tar.gz +7e7d8d0918b4f81f6adde9fcb853a036 jre-8u77-linux-x64.tar.gz diff --git a/jre/Pkgfile b/jre/Pkgfile index a3ecfb8..87eb5e2 100644 --- a/jre/Pkgfile +++ b/jre/Pkgfile @@ -4,8 +4,8 @@ # Packager: Simone Rota, sip at crux dot nu name=jre -version=1.8.0_74 -release=2 +version=1.8.0_77 +release=1 source=(file:///$name-8u${version#*_}-linux-x64.tar.gz) build(){

1 0

AW: Re: repos providing only md5 sums
by Thomas Penteker 23 Mar '16

23 Mar '16

Hello, for the sake of completeness: Fredrik and I starten looking into how we can secure the Ports distribution. Regards, Thomas -------- Ursprüngliche Nachricht -------- Von: Fredrik Rinnestam <fredrik(a)rinnestam.se> Datum: 23.03.2016 10:31 (GMT+01:00) An: crux(a)lists.crux.nu Betreff: Re: repos providing only md5 sums On Wed, Mar 23, 2016 at 10:29:44AM +0100, Erich Eckner wrote: > On 23.03.2016 09:58, Fredrik Rinnestam wrote: > > On Wed, Mar 23, 2016 at 07:38:37AM +0100, Erich Eckner wrote: > >> On 21.03.2016 21:36, Dutch Ingraham wrote: > >>> On Mon, Mar 21, 2016 at 08:31:00AM +0100, Thomas Penteker wrote: > >>>> To fill the missing link to providing integrity and confidentiality, we > >>>> should start cryptographically signing ports on the maintainer's side and > >>>> check these signatures before building/downloading anything. > >> > >> I think, we should definitely allow for signing and verification. > >> However: what's a useful approach for checking Pkgfiles? > >> It's not pkgmk's job, because we want to be able to edit the file. So I > >> think, "ports -u" should check the signature of Pkgfile and pkgmk the > >> ones of the sources? > > > > The current idea is to have git commits signed. This would sign the > > sha256 checksum and a "trusted" chain is established. > > This sounds like a much cleaner solution than signing every individual file. > > > we will obviously lose this when syncing ports with rsync since only > > files are synced. This needs to be solved. > > Maybe, the hash and signature can be added to the synced files (of > course not versioned in git). I don't know the details of the hashing in > git, but in the end it's a hash of hashes of the files (and file > permissions, locations, ...) and some extra information like commit > message and parents? > So given the extra info, one would be able to calculate the hash "by > hand" and verify the signature? > > I know, it sounds hackish - probably not a good idea :-/ > > >> On the other hand: I just noticed, that '--no-check-certificate' is > >> passed as an argument to wget. Why isn't assumed, that a proper > >> certificate is installed? Can this be configured somewhere? > > > > Iirc thats not a default setting. It can be changed in /etc/pkgmk.conf: > > PKGMK_WGET_OPTS="" > > I didn't have any PKGMK_WGET_OPTS defined in /etc/pkgmk.conf (nor in the > Pkgfile), also setting PKGMK_WGET_OPTS="" explicitely didn't change > anything :-/ > > cheers, Erich Yeah I just noticed its hard-coded in pkgmk. You could switch to curl instead - dont think it's hardcoded there. I'll open up a bugreport for the wget issue -- Fredrik Rinnestam _______________________________________________ CRUX mailing list CRUX(a)lists.crux.nu https://lists.crux.nu/mailman/listinfo/crux

1 0

Firefox-45.0 fails to build
by Hazel Russman 22 Mar '16

22 Mar '16

As far as I can see, it's a problem with python. Config has detected python 2.7 on my system but seems to be trying to use the internal one instead: checking for python2.7... /usr/bin/python2.7 Creating Python environment New python executable in /usr/ports/opt/firefox/work/src/firefox-45.0/firefox-shared/_virtualenv/bin/python2.7 Also creating executable in /usr/ports/opt/firefox/work/src/firefox-45.0/firefox-shared/_virtualenv/bin/python Installing setuptools, pip... This then leads to a crash: Complete output from command /usr/ports/opt/firef...ualenv/bin/python2.7 -c "import sys, pip; sys...d\"] + sys.argv[1:]))" setuptools pip: Traceback (most recent call last): File "<string>", line 1, in <module> File "/usr/ports/opt/firefox/work/src/firefox-45.0/python/virtualenv/virtualenv_support/pip-6.0.6-py2.py3-none-any.whl/pip/__init__.py", line 15, in <module> File "/usr/ports/opt/firefox/work/src/firefox-45.0/python/virtualenv/virtualenv_support/pip-6.0.6-py2.py3-none-any.whl/pip/vcs/mercurial.py", line 11, in <module> File "/usr/ports/opt/firefox/work/src/firefox-45.0/python/virtualenv/virtualenv_support/pip-6.0.6-py2.py3-none-any.whl/pip/download.py", line 30, in <module> File "/usr/ports/opt/firefox/work/src/firefox-45.0/python/virtualenv/virtualenv_support/pip-6.0.6-py2.py3-none-any.whl/pip/_vendor/__init__.py", line 81, in load_module ImportError: No module named 'pip._vendor.requests' ...Installing setuptools, pip...done. Traceback (most recent call last): File "/usr/ports/opt/firefox/work/src/firefox-45.0/python/virtualenv/virtualenv.py", line 2352, in <module> main() File "/usr/ports/opt/firefox/work/src/firefox-45.0/python/virtualenv/virtualenv.py", line 825, in main symlink=options.symlink) File "/usr/ports/opt/firefox/work/src/firefox-45.0/python/virtualenv/virtualenv.py", line 993, in create_environment install_wheel(to_install, py_executable, search_dirs) File "/usr/ports/opt/firefox/work/src/firefox-45.0/python/virtualenv/virtualenv.py", line 961, in install_wheel 'PIP_NO_INDEX': '1' File "/usr/ports/opt/firefox/work/src/firefox-45.0/python/virtualenv/virtualenv.py", line 903, in call_subprocess % (cmd_desc, proc.returncode)) OSError: Command /usr/ports/opt/firef...ualenv/bin/python2.7 -c "import sys, pip; sys...d\"] + sys.argv[1:]))" setuptools pip failed with error code 1 Traceback (most recent call last): File "/usr/ports/opt/firefox/work/src/firefox-45.0/python/mozbuild/mozbuild/virtualenv.py", line 485, in <module> manager.ensure() File "/usr/ports/opt/firefox/work/src/firefox-45.0/python/mozbuild/mozbuild/virtualenv.py", line 128, in ensure return self.build() File "/usr/ports/opt/firefox/work/src/firefox-45.0/python/mozbuild/mozbuild/virtualenv.py", line 381, in build self.create() File "/usr/ports/opt/firefox/work/src/firefox-45.0/python/mozbuild/mozbuild/virtualenv.py", line 147, in create raise Exception('Error creating virtualenv.') Exception: Error creating virtualenv. -- H Russman

5 4

Re: CRUX Digest, Vol 138, Issue 11
by Hazel Russman 22 Mar '16

22 Mar '16

> Message: 2 > Date: Mon, 21 Mar 2016 15:05:18 +0100 > From: Filip Bo?ani? Dimovski <rexich(a)riseup.net> > Subject: RE: Firefox-45.0 fails to build > To: Crux mailing list <crux(a)lists.crux.nu> > Message-ID: <mailman.4.1458644403.21675.crux(a)lists.crux.nu> > Content-Type: text/plain; charset="utf-8" > > Hello, just force-rebuild Python and then Firefox will build without issues. > > Filip Dimovski (Rexich) Yes, that was all that was required. Firefox has now built successfully.

1 0