Re: Fixing non-reproducibility in some guile packages

[Andy Wingo]

Hi :)

[+guile-devel]

On Mon 13 Feb 2017 07:18, Maxim Cournoyer  writes:

>>>  ;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
>>>  ;;;   or pass the --no-auto-compile argument to disable.
>>>  ;;; compiling 
>>> /gnu/store/d3gli8g5bv6yhd3qwk5rfzqpsfvnj4lv-guile-next-2.1.5/bin/guild
>
> I've notice this same problem recently while looking at the build-log of
> our GnuCash package.. It seems to be the problem is caused by the Guile
> wanting to auto-compile the guild script, and not being able to as it
> wants to store the compiled version somewhere under $HOME.
>
> Could a generally applicable solution be to distribute a pre-compiled
> guild.go in the store, so that it would use that and never attempt to
> 'auto-compile' it?  This would effectively fix this problem for good
> without having to create workaround such as using environment variables
> or setting HOME to a temp dir.

The compiled .go files that get installed are only for files found in
the Guile load path.  So like when you load (foo bar), it will look for
foo/bar.go in the %load-compiled-path (and foo/bar.scm in the
%load-path).  This lets you compile foo/bar.scm in your build directory
and have the resulting foo/bar.go in the builddir directly usable from
the build-time %load-path / %load-compiled-path, and to install you just
copy into the final %load-path / %load-compiled-path and that works too.

For scripts that are loaded by absolute file name (guild is a prominent
example) that don't live in the %load-path, this technique isn't
directly applicable.  The existing %load-compiled-path is effectively a
function from name-suffix (like "foo/bar.scm") to absolute path of
compiled .go file.  We would need an additional mechanism to be a
function from absolute source file name to absolute path of .go file.
Perhaps that's doable with an additional path.  Perhaps the fallback
compilation path (~/.cache/guile/...) could be generalized to include
something in $prefix also so that packages can install compiled files.
Incidentally probably we should SHA256 the path to prevent so much
directory traversal...

In some future (is it near or far?), the source -> compiled function
needs additional inputs: checksums or timestamps of "build inputs" or
so, so that when for-syntax definitions (like macros) change, users of
those definitions will recompile.  That is a harder problem though.

Andy

Re: [GNU-linux-libre] Free firmware - A redefinition of the term and a new metric for it's measurement.

[Maxim Cournoyer]

Hi,

Christopher Howard  writes:

> On 02/10/2017 08:31 AM, David Craven wrote:
>> Hi Maxim
>> 
>>> +1. I don't see how having blobs helps security at all.
>> 
>> Well the problem I was getting at is that things are not as fixed as
>> they may seem.
>> Quoting wikipedia:
>> 
 Decreasing cost of reprogrammable devices had almost eliminated the market 
 for mask ROM by the year 2000.
>> 
>> Translation: ROM is not RO.
>>

You have a point, although reading the article linked (from Wired), this
kind of attack requires a lot of effort (to reverse engineer the
proprietary interfaces used to reprogram the firmware of a HD). At this
level of seriousness they might as well find other means to get at
you, such as physically altering one of the device you use without you
noticing.

>> It is not a theoretical threat, and just as dangerous as other threats
>> that people put a lot of effort in avoiding [0]
>>

They were using Windows and allowing people to shuffle USB keys. That
fits strangely with "putting a lot of effort in avoiding security risks"
;).

>> I don't see how trusting the manufacturer when buying the product is
>> any different from trusting him down the road. I was talking about
>> malicious third parties. Obviously planting something in difficult to
>> upgrade persistent memory is a lucrative target for attackers -
>> manipulating firmware becomes plain uninteresting in the other case.
>> 
>>> The companies that should be the rewarded are the ones that release
>>> firmware, source code, and tool chain. E.g., Thinkpenguin and the TPE-R1100.
>> 
>>> Indeed, we ought to put our money where our mouth is, i.e. back the
>>> companies which are helping the cause of free software/hardware.
>> 
>> I don't think they actually produce any silicon, toolchain or firmware
>> themselves. At least I didn't find a link to it. So they are basically
>> using other peoples silicon, toolchain and firmware. Giving them
>> credit for complying with the GPL is not quite right either. (But I
>> don't know who's behind the thinkpenguin and it looks like a great
>> accomplishement).
>>

Probably not themselves, but they could hire someone to work on it. I
remember reading a story where ThinkPenguin had been involved in
negotiating with a hardware company and played a part in having that
company agree to release their firmware. Sadly I can't find that story
anymore!  And the company seems active in the free software community
and promoting/defending values of the movement. You can have a look at
their blog to see for yourself (https://www.thinkpenguin.com/blog).

>> To independently verify the claim that the firmware they are using is
>> indeed fixed, would actually require them to release both schematics
>> and datasheets of their designs.
>> 
>> [0] https://www.wired.com/2015/02/nsa-firmware-hacking/
>> 
>
> Stallman did an extensive article in 2015 which I think is relevant to
> this discussion:
>
> https://www.gnu.org/philosophy/free-hardware-designs.en.html
>

A recommended read for anyone interested in the idea of free hardware!
Thanks for sharing.

Maxim


signature.asc
Description: PGP signature

Re: [PATCH 2/3] gnu: Add libfilezilla.

[Maxim Cournoyer]

Hi,

ren...@openmailbox.org writes:

> Hello Maxim,
>
> On 2017-02-12 20:26, Maxim Cournoyer wrote:
>> Hi,
>>
> offering/offers/ or s/offering/provides/
>>
>>> +(license gpl3+)))
>>
>> Only license information I could find is the COPYING file which is
>> GPLv2. I think gpl2+ would be more appropriate.
>>
>
> grepping libfilezilla directory, i see glp2 and gpl3:
>
> libfilezilla-0.9.0/config/depcomp:# the Free Software Foundation;
> either version 2, or (at your option)
> libfilezilla-0.9.0/config/compile:# the Free Software Foundation;
> either version 2, or (at your option)
> libfilezilla-0.9.0/config/missing:# the Free Software Foundation;
> either version 2, or (at your option)
> libfilezilla-0.9.0/config/config.guess:# the Free Software Foundation;
> either version 3 of the License, or
> libfilezilla-0.9.0/config/ltmain.sh:# the Free Software Foundation;
> either version 2 of the License, or
> libfilezilla-0.9.0/config/config.sub:# the Free Software Foundation;
> either version 3 of the License, or

I don't see this in the sources
(https://svn.filezilla-project.org/filezilla/libfilezilla/tags/0.9.0/). I'm
pretty sure those GPLv3 licensed files are part of the GNU
autotools rather than libfilezilla.

> libfilezilla-0.9.0/config/test-driver:# the Free Software Foundation;
> either version 2, or (at your option)
> libfilezilla-0.9.0/configure:# published by the Free Software
> Foundation; either version 2 of
> libfilezilla-0.9.0/COPYING:the Free Software Foundation; either
> version 2 of the License, or
> libfilezilla-0.9.0/m4/ax_check_link_flag.m4:#   Free Software
> Foundation, either version 3 of the License, or (at your
> libfilezilla-0.9.0/m4/ax_check_compile_flag.m4:#   Free Software
> Foundation, either version 3 of the License, or (at your
> libfilezilla-0.9.0/m4/libtool.m4:# published by the Free Software
> Foundation; either version 2 of
> libfilezilla-0.9.0/m4/ax_append_flag.m4:#   Free Software Foundation,
> either version 3 of the License, or (at your

m4 is part of autotools, which is GPLv3. It's not part of the
libfilezilla project.

> libfilezilla-0.9.0/README:the Free Software Foundation; either version
> 2 of the License, or
>
> Should I put both?
> Thanks

I still think gpl2+ is the most accurate if we want to stick to what
upstream says.

Maxim

Re: Fixing non-reproducibility in some guile packages

[Maxim Cournoyer]

Hi!

Christopher Allan Webber  writes:

> Jan Nieuwenhuizen writes:
>
>> While building guile2.2-gdbm-ffi an error is printed that does not
>> prevent the package from being built
>>
>>  @ build-started
>> /gnu/store/z9m20fz1ayyl0g9b4ad6wgmq3fv2h7gi-guile2.2-gdbm-ffi-20120209.fa1d5b6.drv
>> - x86_64-linux
>> /var/log/guix/drvs/z9//m20fz1ayyl0g9b4ad6wgmq3fv2h7gi-guile2.2-gdbm-ffi-20120209.fa1d5b6.drv.bz2
>>  ;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
>>  ;;;   or pass the --no-auto-compile argument to disable.
>>  ;;; compiling 
>> /gnu/store/d3gli8g5bv6yhd3qwk5rfzqpsfvnj4lv-guile-next-2.1.5/bin/guild
>>  ;;; WARNING: compilation of 
>> /gnu/store/d3gli8g5bv6yhd3qwk5rfzqpsfvnj4lv-guile-next-2.1.5/bin/guild 
>> failed:
>>  ;;; ERROR: failed to create path for auto-compiled file

I've notice this same problem recently while looking at the build-log of
our GnuCash package.. It seems to be the problem is caused by the Guile
wanting to auto-compile the guild script, and not being able to as it
wants to store the compiled version somewhere under $HOME.

Could a generally applicable solution be to distribute a pre-compiled
guild.go in the store, so that it would use that and never attempt to
'auto-compile' it?  This would effectively fix this problem for good
without having to create workaround such as using environment variables
or setting HOME to a temp dir.

WDYT?

Maxim


signature.asc
Description: PGP signature

Re: [PATCH 2/3] gnu: Add libfilezilla.

[rennes]

Hello Maxim,

On 2017-02-12 20:26, Maxim Cournoyer wrote:

Hi,


offering/offers/ or s/offering/provides/



+(license gpl3+)))


Only license information I could find is the COPYING file which is
GPLv2. I think gpl2+ would be more appropriate.



grepping libfilezilla directory, i see glp2 and gpl3:

libfilezilla-0.9.0/config/depcomp:# the Free Software Foundation; either 
version 2, or (at your option)
libfilezilla-0.9.0/config/compile:# the Free Software Foundation; either 
version 2, or (at your option)
libfilezilla-0.9.0/config/missing:# the Free Software Foundation; either 
version 2, or (at your option)
libfilezilla-0.9.0/config/config.guess:# the Free Software Foundation; 
either version 3 of the License, or
libfilezilla-0.9.0/config/ltmain.sh:# the Free Software Foundation; 
either version 2 of the License, or
libfilezilla-0.9.0/config/config.sub:# the Free Software Foundation; 
either version 3 of the License, or
libfilezilla-0.9.0/config/test-driver:# the Free Software Foundation; 
either version 2, or (at your option)
libfilezilla-0.9.0/configure:# published by the Free Software 
Foundation; either version 2 of
libfilezilla-0.9.0/COPYING:the Free Software Foundation; either 
version 2 of the License, or
libfilezilla-0.9.0/m4/ax_check_link_flag.m4:#   Free Software 
Foundation, either version 3 of the License, or (at your
libfilezilla-0.9.0/m4/ax_check_compile_flag.m4:#   Free Software 
Foundation, either version 3 of the License, or (at your
libfilezilla-0.9.0/m4/libtool.m4:# published by the Free Software 
Foundation; either version 2 of
libfilezilla-0.9.0/m4/ax_append_flag.m4:#   Free Software Foundation, 
either version 3 of the License, or (at your
libfilezilla-0.9.0/README:the Free Software Foundation; either version 2 
of the License, or


Should I put both?
Thanks

Re: [PATCH 3/3] gnu: Add filezilla.

[Maxim Cournoyer]

Hi,

rennes  writes:

> * gnu/packages/ftp.scm (filezilla): New variable.
> ---
>  gnu/packages/ftp.scm | 48 +++-
>  1 file changed, 47 insertions(+), 1 deletion(-)
>
> diff --git a/gnu/packages/ftp.scm b/gnu/packages/ftp.scm
> index 0fef1b160..129f04ef6 100644
> --- a/gnu/packages/ftp.scm
> +++ b/gnu/packages/ftp.scm
> @@ -27,12 +27,20 @@
>#:use-module (guix packages)
>#:use-module (gnu packages)
>#:use-module (gnu packages autotools)
> -  #:use-module (gnu packages check)  
> +  #:use-module (gnu packages glib)
> +  #:use-module (gnu packages gtk)

Minor thing, and I'm not sure if we have a convention for this, but it'd
be neat to keep the use-module statements ordered alphabetically.

> +  #:use-module (gnu packages check)
> +  #:use-module (gnu packages databases)
> +  #:use-module (gnu packages freedesktop)  
>#:use-module (gnu packages gettext)
> +  #:use-module (gnu packages libidn)  
>#:use-module (gnu packages ncurses)
> +  #:use-module (gnu packages nettle)  
>#:use-module (gnu packages readline)
>#:use-module (gnu packages pkg-config)
>#:use-module (gnu packages tls)
> +  #:use-module (gnu packages wxwidgets)
> +  #:use-module (gnu packages xml)  
>#:use-module (gnu packages compression))
>  
>  (define-public lftp
> @@ -183,3 +191,41 @@ as required.")
>   "This package offering some basic functionality to build 
> high-performing,
>  platform-independent programs.")
>  (license gpl3+)))
> +
> +(define-public filezilla
> +  (package
> +(name "filezilla")
> +(version "3.24.0")
> +(source
> + (origin
> +   (method url-fetch)
> +   (uri (string-append "https://sourceforge.net/projects/"; name
> +   "/files/FileZilla_Client/" version
> +   "/FileZilla_" version "_src" ".tar.bz2"))
> +   (sha256
> +(base32
> + "1bacrl8lj90hqbh129hpbgqj78k1i84j83rkzn507jnykj4x8p9x"
> +(build-system gnu-build-system)
> +(native-inputs
> + `(("gettext" ,gettext-minimal)
> +   ("pkg-config" ,pkg-config)
> +   ("pugixml" ,pugixml)
> +   ("xdg-utils" ,xdg-utils)))
> +(inputs
> + `(("dbus" ,dbus)
> +   ("gnutls" ,gnutls)
> +   ("gtk+" ,gtk+)
> +   ("libfilezilla" ,libfilezilla)
> +   ("libidn" ,libidn)
> +   ("nettle" ,nettle)
> +   ("sqlite" ,sqlite)
> +   ("wxwidgets" ,wxwidgets)))
> +(home-page "https://filezilla-project.org";)
> +(synopsis "Full-featured graphical FTP/FTPS/SFTP client")
> +(description
> + "Filezilla client supports FTP, FTP over SSL/TLS (FTPS),
> +SSH File Transfer Protocol (SFTP), HTTP/1.1, SOCKS5, FTP-Proxy, IPv6
> +and others features such as bookmarks, drag and drop, filename filters,
> +directory comparison and more.")
> +(license gpl3+)

Again, I'm under the impression that this should rather be gpl2+. I'd be
happy to be proven wrong otherwise!

> +(properties '((upstream-name . "FileZilla")

Otherwise LGTM (haven't tested though).

Maxim


signature.asc
Description: PGP signature

Re: [PATCH 2/3] gnu: Add libfilezilla.

[Maxim Cournoyer]

Hi,

rennes  writes:

> * gnu/packages/ftp.scm (libfilezilla): New variable.
> ---
>  gnu/packages/ftp.scm | 24 
>  1 file changed, 24 insertions(+)
>
> diff --git a/gnu/packages/ftp.scm b/gnu/packages/ftp.scm
> index 7380fcfc3..0fef1b160 100644
> --- a/gnu/packages/ftp.scm
> +++ b/gnu/packages/ftp.scm
> @@ -3,6 +3,7 @@
>  ;;; Copyright © 2015 Andreas Enge 
>  ;;; Copyright © 2015 Mark H Weaver 
>  ;;; Copyright © 2016 Tobias Geerinckx-Rice 
> +;;; Copyright © 2017 Rene Saavedra 
>  ;;;
>  ;;; This file is part of GNU Guix.
>  ;;;
> @@ -26,6 +27,7 @@
>#:use-module (guix packages)
>#:use-module (gnu packages)
>#:use-module (gnu packages autotools)
> +  #:use-module (gnu packages check)  
>#:use-module (gnu packages gettext)
>#:use-module (gnu packages ncurses)
>#:use-module (gnu packages readline)
> @@ -159,3 +161,25 @@ maintaining a web page or other FTP archive.  It 
> synchronizes a set of
>  local files to a remote server by performing uploads and remote deletes
>  as required.")
>  (license gpl2+)))
> +
> +(define-public libfilezilla
> +  (package
> +(name "libfilezilla")
> +(version "0.9.0")
> +(source
> + (origin
> +   (method url-fetch)
> +   (uri (string-append "http://download.filezilla-project.org/";
> +   name "/" name "-" version ".tar.bz2"))
> +   (sha256
> +(base32
> + "0340v5xs48f28q2d16ldb9359dkzlhl4l449mgyv3qabnlz2pl21"
> +(build-system gnu-build-system)
> +(native-inputs
> + `(("cppunit" ,cppunit)))
> +(home-page "https://lib.filezilla-project.org";)
> +(synopsis "Cross-platform C++ library used by Filezilla client")
> +(description
> + "This package offering some basic functionality to build 
> high-performing,
> +platform-independent programs.")

s/offering/offers/ or s/offering/provides/

> +(license gpl3+)))

Only license information I could find is the COPYING file which is
GPLv2. I think gpl2+ would be more appropriate.

Maxim

Re: Archive authentication & ‘guix challenge’

[Maxim Cournoyer]

Hello,

l...@gnu.org (Ludovic Courtès) writes:

> myglc2  skribis:
>
>> On 02/09/2017 at 17:36 Ludovic Courtès writes:
>
> [...]
>
>>> Could it be that the ‘guix archive’ you ran uses a configuration
>>> directory other than this one?  What does:
>>>
>>>   guile -c '(use-modules (guix config)) (pk %config-directory)'
>>>
>>> print?

I remember being equally confused by not finding the key imported in the
/etc/guix/acl file, as per the manual.

On my GuixSD system, the value of %config-directory is:
"/usr/local/etc/guix", and the file "/usr/local/etc/guix/acl" does
contain multiple times the public key of Bayfront, which must be due
to passed attempts at adding the Bayfront key using "guix archive".

Maxim


signature.asc
Description: PGP signature

Re: Running services in containers

[Maxim Cournoyer]

Hi!

Ricardo Wurmus  writes:

> Ludovic Courtès  writes:
>
>> Those who didn’t have the luck to be at FOSDEM missed this not-so-visual
>> demo I made of a Shepherd service running in a container.  :-)
>>
>> I’ve polished the thing on my way back and pushed the result, using
>> BitlBee as an example:
>>
>>   
>> http://git.savannah.gnu.org/cgit/guix.git/commit/?id=63302a4e55241a41eab4c21d7af9fbd0d5817459
>>   
>> http://git.savannah.gnu.org/cgit/guix.git/commit/?id=a062b6ca99ad61c9df473fe49a93d69f9698c59d
>>
>
> This is very cool!  I’m amazed at how you got this ready in time for
> your talk.  I’m sure you didn’t just keep this under wraps for weeks :)
>

+1. I can see myself experimenting with this for SSH soon. Thanks for
providing the bits required to do this and sharing!

Maxim


signature.asc
Description: PGP signature

Re: Commits signed by key not registered on Savannah

[Leo Famulari]

On Sun, Feb 12, 2017 at 04:55:14PM -0500, Mark H Weaver wrote:
> David Craven  writes:
> > The integrity of our source code is given by peer review - we are
> > subscribed to the commits ML so we see other peoples commits.
> 
> If we're concerned about security (and we should be), then we should not
> rely on the commits mailing list (or any web interface) to show us the
> same set of commits that have been pushed to the repo.  An attacker
> could prevent some of those emails from reaching us, or modify them in
> transit to introduce a malicious commit into our repository without it
> being noticed.

In fact, the guix-commits mailing list was not sending any messages for
a few days recently:

http://lists.gnu.org/archive/html/savannah-hackers-public/2017-02/msg00030.html


signature.asc
Description: PGP signature

Re: Commits signed by key not registered on Savannah

[Mark H Weaver]

David Craven  writes:
> The integrity of our source code is given by peer review - we are
> subscribed to the commits ML so we see other peoples commits.

If we're concerned about security (and we should be), then we should not
rely on the commits mailing list (or any web interface) to show us the
same set of commits that have been pushed to the repo.  An attacker
could prevent some of those emails from reaching us, or modify them in
transit to introduce a malicious commit into our repository without it
being noticed.

It's better to "git pull" and read the commits directly out of our local
copy of the git repository.

  Mark

Re: [PATCH] gnu: ffmpeg: Build with SDL support.

[Marius Bakke]

Arun Isaac  writes:

> SDL is required for the `ffplay' executable to be built.
>
> * gnu/packages/video.scm (ffmpeg)[inputs]: Add sdl2.

This increases ffmpegs closure size from 518.9 MiB to 525.7 MiB, which
seems fine to me. If no one objects I will push this tomorrow or so.


signature.asc
Description: PGP signature

Re: [PATCH] gnu: lcms: Update to 2.8.

[Marius Bakke]

Alex Vong  writes:

>>> Besides, the security bug in which 'lcms-fix-out-of-bounds-read.patch'
>>> fixed has been assigned CVE-2016-10165 according to [0], should we
>>> change the name of the patch?
>>>
>>> [0]: https://bugzilla.redhat.com/show_bug.cgi?id=1367357
>>
>> Good catch. Would you like to do it?
>>
>> Could you submit this patch against the 'core-updates' branch? LCMS
>> causes ~1800 rebuilds which is too much for 'master'. The CVE patch has
>> also been 'un-grafted' in core-updates, so the context will be slightly
>> different. TIA!
>
> Sure, the patches are here:

Applied, thank you!


signature.asc
Description: PGP signature

Re: bug#25463: guile-2.0.13 Check errors

[Ludovic Courtès]

Hello!

Manolis Ragkousis  skribis:

> Locally on Hurd I am using this patch
> http://paste.lisp.org/display/338954 on the glibc/hurd package to work
> around that test failure. Ideally we need to modify the way guile
> handles time.[1]

Does ‘glibc/hurd’ have this patch in ‘core-updates’?  Should it?

Would it make sense to address this issue in Guile instead of libc,
Richard?  I guess the answer depends on how many programs make this
assumption besides Guile.

Thanks,
Ludo’.

Re: Add murmur.

[David Craven]

Hi Hartmut,

Sorry for my snide remark...

>> This hypothetical attacker is trying to escalate privileges. I don't
>> see how starting an unprivileged process would help with that.
>
> Well, simply by an exploiting a bug in that software. This is a quite
> common case :-)

It is my understanding that exploiting a bug in that software can not
help gaining access to privileges that the exploited software does not
have, since this would be a kernel bug.

All attacks that I'm aware of buffer overflow, cross site scripting, sql
injection rely on inserting some code that gets run. But this code
shares the process of the vulnerable program so by extension it shares
it's privileges.

If an attacker already has the privileges required to start the software
I don't think it's possible to gain any more privileges unless that software
has the setuid bit set.

But I have a tendency to oversimplify things, because it gives me the
feeling that I understand it =P

David

Re: Add murmur.

[pelzflorian (Florian Pelz)]

On 02/12/2017 06:01 PM, Hartmut Goebel wrote:
> Am 12.02.2017 um 15:37 schrieb David Craven:
>> I think that it is a minor
>> issue at best, since anything that isn't accessible over the network or 
>> running
>> with any sort of privileges is not very useful.
> 
> I strongly disagree!
> 
> Every piece of software available on the system may the intruder. The
> server may not be running so it can not be attacked in the first place.
> But if an intruder gains (unprivileged) access to the system, he might
> be able to start that server software. Then he might use it for
> privilege escalation (if the server software is vulnerable), as a
> back-channel or for attacking further systems.
> 

An attacker with enough privileges to run Murmur has enough privileges
to install Murmur anyway (perhaps but not necessarily by using Guix). Do
I misunderstand?

Regards,
Florian

Re: Fixing non-reproducibility in some guile packages

[Christopher Allan Webber]

Jan Nieuwenhuizen writes:

> While building guile2.2-gdbm-ffi an error is printed that does not
> prevent the package from being built
>
>  @ build-started 
> /gnu/store/z9m20fz1ayyl0g9b4ad6wgmq3fv2h7gi-guile2.2-gdbm-ffi-20120209.fa1d5b6.drv
>  - x86_64-linux 
> /var/log/guix/drvs/z9//m20fz1ayyl0g9b4ad6wgmq3fv2h7gi-guile2.2-gdbm-ffi-20120209.fa1d5b6.drv.bz2
>  ;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
>  ;;;   or pass the --no-auto-compile argument to disable.
>  ;;; compiling 
> /gnu/store/d3gli8g5bv6yhd3qwk5rfzqpsfvnj4lv-guile-next-2.1.5/bin/guild
>  ;;; WARNING: compilation of 
> /gnu/store/d3gli8g5bv6yhd3qwk5rfzqpsfvnj4lv-guile-next-2.1.5/bin/guild failed:
>  ;;; ERROR: failed to create path for auto-compiled file 
> "/gnu/store/d3gli8g5bv6yhd3qwk5rfzqpsfvnj4lv-guile-next-2.1.5/bin/guild"
>  wrote 
> `/gnu/store/xskgkfsxz936nifjs8vxqwk95kf62ia8-guile2.2-gdbm-ffi-20120209.fa1d5b6/share/guile/site/2.2/gdbm.go'
>  @ build-succeeded 
> /gnu/store/z9m20fz1ayyl0g9b4ad6wgmq3fv2h7gi-guile2.2-gdbm-ffi-20120209.fa1d5b6.drv
>  -
>  
> /gnu/store/xskgkfsxz936nifjs8vxqwk95kf62ia8-guile2.2-gdbm-ffi-20120209.fa1d5b6
>  22:00:06 janneke@dundal:~/src/guix

Ah yeah, okay!  I fixed this by adding GUILE_AUTO_COMPILE=0 to the
environment while compiling.  New patch attached!

From 447cf04e0fc5947e8384851ecfa9fffd61638c39 Mon Sep 17 00:00:00 2001
From: Christopher Allan Webber 
Date: Fri, 10 Feb 2017 19:24:57 -0600
Subject: [PATCH] guile-gdbm-ffi: Write to correct guile output directory and
 use guild.

* gnu/packages/guile.scm (make-guile-gdbm-ffi): New variable.
Adapts from the previous guile-gdbm-ffi definition.  Also fixes
a bug where the guild command was not getting called, and instead
was calling the internal guile compile-file procedure.  This meant
that the package produced was dependent on whatever version of
guile was powering Guix at the time.  Also set GUILE_AUTO_COMPILE
to 0 to avoid gnarly looking warnings during build.
(guile-gdbm-ffi, guile2.2-gdbm-ffi): Use make-guile-gdbm-ffi.
---
 gnu/packages/guile.scm | 31 +--
 1 file changed, 21 insertions(+), 10 deletions(-)

diff --git a/gnu/packages/guile.scm b/gnu/packages/guile.scm
index 3e8ab007b..6e1831fb4 100644
--- a/gnu/packages/guile.scm
+++ b/gnu/packages/guile.scm
@@ -825,9 +825,11 @@ inspired by the SCSH regular expression system.")
 ;; There are two guile-gdbm packages, one using the FFI and one with
 ;; direct C bindings, hence the verbose name.
 
-(define-public guile-gdbm-ffi
+(define (make-guile-gdbm-ffi guile-2.2?)
   (package
-(name "guile-gdbm-ffi")
+(name (if guile-2.2?
+  "guile2.2-gdbm-ffi"
+  "guile-gdbm-ffi"))
 (version "20120209.fa1d5b6")
 (source (origin
   (method git-fetch)
@@ -844,11 +846,14 @@ inspired by the SCSH regular expression system.")
((guix build utils))
#:builder
(begin
- (use-modules (guix build utils)
-  (system base compile))
+ (use-modules (guix build utils))
+
+ (setenv "GUILE_AUTO_COMPILE" "0")
 
  (let* ((out (assoc-ref %outputs "out"))
-(module-dir (string-append out "/share/guile/site/2.0"))
+(module-dir (string-append out "/share/guile/site/"
+   ,(if guile-2.2?
+"2.2" "2.0")))
 (source (assoc-ref %build-inputs "source"))
 (doc (string-append out "/share/doc"))
 (guild (string-append (assoc-ref %build-inputs "guile")
@@ -856,7 +861,10 @@ inspired by the SCSH regular expression system.")
 (gdbm.scm-dest
  (string-append module-dir "/gdbm.scm"))
 (gdbm.go-dest
- (string-append module-dir "/gdbm.go")))
+ (string-append module-dir "/gdbm.go"))
+(compile-file
+ (lambda (in-file out-file)
+   (system* guild "compile" "-o" out-file in-file
;; Make installation directories.
(mkdir-p module-dir)
(mkdir-p doc)
@@ -874,10 +882,10 @@ inspired by the SCSH regular expression system.")
   (assoc-ref %build-inputs "gdbm"
 
;; compile to the destination
-   (compile-file gdbm.scm-dest
- #:output-file gdbm.go-dest)
+   (compile-file gdbm.scm-dest gdbm.go-dest)
 (inputs
- `(("guile" ,guile-2.0)))
+ `(("guile" ,(if guile-2.2?
+ guile-next guile-2.0
 (propagated-inputs
  `(("gdbm" ,gdbm)))
 (home-page "https://github.com/ijp/guile-gdbm";)
@@ -887,8 +895,11 @@ inspired by the SCSH regular expression system.")
 Guile's foreign function interface.")
 (license gpl3+)))
 
+(define-public guile-gdbm-ffi
+  (make-guile-gdbm-ffi #f))
+
 (define-public guile2.2-gdb

Re: Add murmur.

[Hartmut Goebel]

Am 12.02.2017 um 15:37 schrieb David Craven:
> I think that it is a minor
> issue at best, since anything that isn't accessible over the network or 
> running
> with any sort of privileges is not very useful.

I strongly disagree!

Every piece of software available on the system may the intruder. The
server may not be running so it can not be attacked in the first place.
But if an intruder gains (unprivileged) access to the system, he might
be able to start that server software. Then he might use it for
privilege escalation (if the server software is vulnerable), as a
back-channel or for attacking further systems.


> This hypothetical attacker is trying to escalate privileges. I don't
> see how starting an unprivileged process would help with that.

Well, simply by an exploiting a bug in that software. This is a quite
common case :-)

-- 

Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: server and client in one package -> security issue

[Hartmut Goebel]

Am 12.02.2017 um 13:53 schrieb David Craven:
> By development files I assume you mean header files? I don't see how those can
> pose a security problem. Can you elaborate?

Yes, I meant header files, but also pkgconfig files and all this stuff
(including documentation). Having this (and compilers, etc.) available
on the target machine makes it *much* easier for an intruder to compile
attack tools for malware on the target. If these are missing, the
intruder needs to collect a lot of information first to be able to build
tools for the target.

Of course this is not a silver bullet, but it one piece of protection.
Like a lock on the door: It may take the burglar only 2 Minutes to open
it, but less skilled ones may be discouraged. Or these 2 Minutes may
give you some advantage.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

FAIL: tests/cpan.scm, tests/gem.scm, tests/pypi.scm, tests/crate.scm

[John Darrington]

After merging a very recent master, I get four test failures when running make 
check:

FAIL: tests/pypi.scm
FAIL: tests/cpan.scm
FAIL: tests/gem.scm
FAIL: tests/crate.scm


Looking in test-suite.log there is the rather odd messge:

actual-value: #f
actual-error:
+ (wrong-number-of-args
+   #f
+   "Wrong number of arguments to ~A"
+   (#)
+   #f)
result: FAIL



I know that it used to work, so using git bisect I tracked this down to
commit 81e0bc1834490a1a8092c75a0733b15c2b407285  and reverting this commit
indeed fixes the problem.

What does this commit do?  Do we really need it?

J'





-- 
Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.



signature.asc
Description: Digital signature

Re: Auditing CPE names

[Leo Famulari]

On Sat, Feb 11, 2017 at 02:53:46PM -0500, Leo Famulari wrote:
> It's important to name the package in accordance with the CPE or set
> the cpe-name property, or else `guix lint -c cve` won't work for that
> package.

In commit 84b60a7cdfc (gnu: lcms: Fix an out-of-bounds read.) I tried to
set the cpe-name but couldn't get it to work, and then I forgot to
remove it from the commit message before pushing.

Anyways, I still can't get it to work after trying again today.

This package should be reported as vulnerable to CVE-2016-10165. The CVE
database for 2016 includes this line in the entry for that CVE:



But when setting the cpe-name to little_cms_color_engine, the linter
still doesn't report the vulnerability.

Any ideas?


signature.asc
Description: PGP signature

Re: Auditing CPE names

[Ludovic Courtès]

Leo Famulari  skribis:

> I wonder if anyone checks the Common Platform Enumeration (CPE) names of
> new packages when creating them?
>
> It's important to name the package in accordance with the CPE or set
> the cpe-name property, or else `guix lint -c cve` won't work for that
> package.
>
> There is an example of setting the cpe-name in the package definition of
> isc-dhcp, where the cpe-name is 'dhcp'.
>
> Maybe we should audit the whole package set to find packages that appear
> to not be covered by CPE.

I think it’s a good idea, everyone should check whether important
packages are covered.

Packages that are definitely not covered are those for which we add a
prefix to the upstream name, such as “python-”.  We could tell ‘guix
lint -c cve’ to strip common prefixes like this one, but I suspect this
won’t be enough.

Thoughts?

Ludo’.

Re: Add murmur.

[David Craven]

> You read too much between the lines in my words.

> I'm not counting on the certifications of Harmut. I simply agree with
> the reasoning that no client and server should be combined if possible
> to limit the attack surface. That's all.

That may be true. It was my intention to back Ludo. I think that it is a minor
issue at best, since anything that isn't accessible over the network or running
with any sort of privileges is not very useful.

An attack usually involves exploiting a service for remote code
execution, followed
by privilege escalation and finally securing access to the system and
cleaning up
traces.

This is an unprivileged binary on a server, and it isn't even running.
Exploiting any
bugs in the client would require starting the client first. This means
that an attacker
has already gained physical access or is able to perform remote code execution.

This hypothetical attacker is trying to escalate privileges. I don't
see how starting
an unprivileged process would help with that.

But then again - I'm not an expert and don't have any credentials - so
I'd be interested
to know if there is a way of exploiting this.

How to M-x debbugs-gnu with new guix-patches

[Christopher Allan Webber]

So!  We have a new debbugs tracking of guix-patches.  Great!  Those who
are emacs users in the know probably like to use the M-x debbugs-gnu
interface.  Here's what you need to do:

Add this to your .emacs:
  (add-to-list 'debbugs-gnu-all-packages "guix-patches")

Now open up debbugs-gnu:
  C-u M-x debbugs-gnu   guix-patches  n y

And now you have a nice emacs interface!

I found this documentation on debbugs useful:
  https://www.debian.org/Bugs/Reporting

And also, maybe you want to tag bugs or etc.  Use the 'C' key from the
emacs interface!

Happy bug triaging!

Re: [PATCH 1/1] gnu: screen: Fix CVE-2017-5618.

[Ludovic Courtès]

Leo Famulari  skribis:

> * gnu/packages/patches/screen-CVE-2017-5618.patch: New file.
> * gnu/local.mk (dist_patch_DATA): Add it.
> * gnu/packages/screen.scm (screen)[source]: Use it.

LGTM, thank you!

Ludo'.

New guix-patches mailing list hooked to Debbugs!

[Ludovic Courtès]

Hello Guix!

We now have a new guix-patc...@gnu.org mailing list hooked to Debbugs to
handle patches!

  https://bugs.gnu.org/guix-patches
  https://lists.gnu.org/mailman/listinfo/guix-patches

You’re welcome to subscribe to it right away.

Patches should now be sent to guix-patc...@gnu.org, especially patches
that relate to packaging (other patches that touch Guix or GuixSD core
can still be discussed on guix-devel@gnu.org, if you prefer).  General
development discussions will still take place on guix-devel@gnu.org.

Each message sent to guix-patches creates a Debbugs entry, as is the
case with bug-guix.  One can then follow up to n...@debbugs.gnu.org,
where NNN is the bug number.

For patch series, please read Glenn’s suggestions at:

  https://debbugs.gnu.org/15361

For general questions about Debbugs, see:

  https://debbugs.gnu.org/Advanced.html

If you’re using Emacs, consider installing ‘emacs-debbugs’ to access the
patch database; it’s very convenient.

Last, I need a couple of people to sign up as admins for the mailing
list, as we did for the other MLs.  If nobody volunteers, I’ll take two
people at random, muahaha.  ;-)  (Being an ML admin requires no work,
except in the occasional cases where the ML parameters need to be
tweaked, etc.)

Enjoy!

Ludo’.


signature.asc
Description: PGP signature

Re: [PATCH] gnu: Add tftp-hpa.

[Gábor Boskovits]

Hello!

#1 A post on the list cought my attention regarding security of packages
with both server and client. I think that should also apply to this package.
I am waiting for follow ups on that.
#2 I have discussed the licensing issues with Thomas Danckaert, but waiting
for confirmation wether the licence is correct now.
I will try to contact upstream, if they consider relicensing the
contribution under isc.
#3 I am still waiting for assistance regading the category of this package.
My candidtates: networking, ftp (but this is tftp),admin (because isc-dhcp
is there) or maybe something like network-infrastucture. I have seen
dnsmasq in dns, which also provides tftp, but I don't think this package
belongs to dns.

2017-02-06 23:58 GMT+01:00 Boskovits, Gábor :

> * gnu/packages/tftp-hpa.scm: New file.
> ---
>  gnu/packages/tftp-hpa.scm | 27 +++
>  1 file changed, 27 insertions(+)
>  create mode 100644 gnu/packages/tftp-hpa.scm
>
> diff --git a/gnu/packages/tftp-hpa.scm b/gnu/packages/tftp-hpa.scm
> new file mode 100644
> index 0..44a008698
> --- /dev/null
> +++ b/gnu/packages/tftp-hpa.scm
> @@ -0,0 +1,27 @@
> +(define-module (gnu packages tftp-hpa)
> +  #:use-module (guix packages)
> +  #:use-module (guix download)
> +  #:use-module (guix build-system gnu)
> +  #:use-module (guix licenses))
> +
> +(define-public tftp-hpa
> +  (package
> +(name "tftp-hpa")
> +(version "5.2")
> +(source (origin
> +  (method url-fetch)
> +  (uri (string-append "https://www.kernel.org/pub/software/";
> +  "network/tftp/tftp-hpa/tftp-hpa-"
> version
> +  ".tar.xz"))
> +  (sha256
> +   (base32
> +"12vidchglhyc20znq5wdsbhi9mqg90
> jnl7qr9qs8hbvaz4fkdvmg"
> +(build-system gnu-build-system)
> +(arguments `(#:tests? #f)) ; no test target
> +(synopsis "HPA's tftp client")
> +(description
> + "This is a tftp client derived from OpenBSD tftp with some extra
> options
> +added and bugs fixed.  The source includes readline support but it is not
> +enabled due to license conflicts between the BSD advertising clause and
> the GPL.")
> +(home-page "http://git.kernel.org/cgit/network/tftp/tftp-hpa.git/
> about/")
> +(license (list gpl1 bsd-4
> --
> 2.11.0
>
>

Re: Debbugs handling of Guix patches

[Ludovic Courtès]

Glenn Morris  skribis:

> I see you got this sorted out, so I've now completed the debbugs part.
> It may take an hour or so for the mailing list redirection to take effect.

It seems to be working now:

  https://debbugs.gnu.org/cgi/pkgreport.cgi?pkg=guix-patches

Thanks, Glenn!

Ludo'.

Re: Add murmur.

[ng0]

On 17-02-12 14:57:05, David Craven wrote:
> > Okay. I prefer to wait for the outcome of the discussion around
> > server+client merging. I'm in favor of separating for the reasons Harmut
> > mentioned.
> 
> This is a free software community. Anyone that needs to assert his authority
> with external certifications rather than actions and sound reasoning is in the
> wrong place here.
> 

You read too much between the lines in my words.

I'm not counting on the certifications of Harmut. I simply agree with
the reasoning that no client and server should be combined if possible
to limit the attack surface. That's all.
-- 
ng0 -- https://www.inventati.org/patternsinthechaos/

Re: Announcement regarding the oss-security mailing list

[Ludovic Courtès]

Hi Leo,

Leo Famulari  skribis:

> I look at the lwn.net security advisories, the Debian security-announce
> mailing list, `guix lint -c cve`, the upstream bug trackers of a handful
> of packages, and even some Twitter personalities.

For me it’s mostly oss-sec, LWN, and ‘guix lint’.

The good thing with the new MITRE policy is that the CVE database will
be more up-to-date, IIUC.  Until now, they’d quickly reserve an ID for
issues reported to oss-sec, but then it would take time until the CVE
database would be updated to contain all the info (for the recent Guile
CVEs, they asked me to give them the details again after two months or
so…).  As a side effect, ‘guix lint -c cve’ should become more useful.

Ludo’.

Re: Add murmur.

[David Craven]

> Okay. I prefer to wait for the outcome of the discussion around
> server+client merging. I'm in favor of separating for the reasons Harmut
> mentioned.

This is a free software community. Anyone that needs to assert his authority
with external certifications rather than actions and sound reasoning is in the
wrong place here.

Re: [Savannah-hackers-public] New guix-patches mailing list not showing up on Mailman

[Ludovic Courtès]

Karl Berry  skribis:

> I created a new ‘guix-patches’ mailing lists ~48h ago on Savannah.  
>
> I just created it by hand. Assaf is looking into the PHP<->Savannah
> linkage/breakage. --best, karl.

Perfect.  Thank you Karl & Assaf!

Ludo’.

Re: Add murmur.

[ng0]

On 17-02-12 14:37:53, Ludovic Courtès wrote:
> ng0  skribis:
> 
> > On 17-02-11 15:31:15, Ludovic Courtès wrote:
> >> ng0  skribis:
> 
> [...]
> 
> >> > As far as I know right now, it does not have any graphical features or
> >> > dependencies.
> >> >
> >> > mumble:murmur -> total: 1072.6 MiB
> >> > mumble:out-> total: .2 MiB
> >> 
> >> And what about the total reported by
> >> 
> >>   guix size mumble:murmur mumble:out
> 
> [...]
> 
> > store item   total
> > self
> > /gnu/store/1zdk5x87ig5zvqcn5f8lllnmrywg9asa-mumble-1.2.19 .2
> >  5.6   0.5%
> > /gnu/store/l4as1725kds2rrpz2l1pcfz8bjn256qd-mumble-1.2.19-murmur  1072.6
> >  1.2   0.1%
> 
> [...]
> 
> > total: 1112.3 MiB
> 
> For 1.2 MiB, I’d say keep both in the same output.
> 
> Could you update the patch accordingly?
> 
> Thank you!
> 
> Ludo’.
> 

Okay. I prefer to wait for the outcome of the discussion around
server+client merging. I'm in favor of separating for the reasons Harmut
mentioned.

-- 
ng0 -- https://www.inventati.org/patternsinthechaos/

Re: bug#25463: guile-2.0.13 Check errors

[Manolis Ragkousis]

Hello Renes,

On 02/12/17 10:37, ren...@openmailbox.org wrote:
> Now the following error is left:
> 
> Running time.test
> FAIL: time.test: internal-time-units-per-second: versus times and sleep
> Running tree-il.test
> 
> Totals for this test run:
> passes: 39537
> failures:   1
> unexpected passes:  0
> expected failures:  9
> unresolved test cases:  582
> untested test cases:1
> unsupported test cases: 10
> errors: 0
> 
> 

Locally on Hurd I am using this patch
http://paste.lisp.org/display/338954 on the glibc/hurd package to work
around that test failure. Ideally we need to modify the way guile
handles time.[1]

Manolis


[1]
https://lists.gnu.org/archive/html/bug-hurd/2015-10/msg00019.html

Re: Commits signed by key not registered on Savannah

[Ludovic Courtès]

Hi!

The idea that I had while trying to see how to map TUF to Git¹ was to
store keys in the Git repo we’re authenticating.  We’d store a list of
“authorized keys” for each “role” that we define.  One of the roles
would be “update the authorized committer keys”, for instance.

Thus, to authenticate a Git commit, we’d have to check whether it was
made by a committer whose key was marked as authorized in the previous
commit.

I’d like to toy with this idea and see whether it’s hard to implement
and how well that would perform.

Thoughts?

Ludo’.

¹ https://bugs.gnu.org/22883

Re: Add murmur.

[Ludovic Courtès]

ng0  skribis:

> On 17-02-11 15:31:15, Ludovic Courtès wrote:
>> ng0  skribis:

[...]

>> > As far as I know right now, it does not have any graphical features or
>> > dependencies.
>> >
>> > mumble:murmur -> total: 1072.6 MiB
>> > mumble:out-> total: .2 MiB
>> 
>> And what about the total reported by
>> 
>>   guix size mumble:murmur mumble:out

[...]

> store item   totalself
> /gnu/store/1zdk5x87ig5zvqcn5f8lllnmrywg9asa-mumble-1.2.19 .2 
> 5.6   0.5%
> /gnu/store/l4as1725kds2rrpz2l1pcfz8bjn256qd-mumble-1.2.19-murmur  1072.6 
> 1.2   0.1%

[...]

> total: 1112.3 MiB

For 1.2 MiB, I’d say keep both in the same output.

Could you update the patch accordingly?

Thank you!

Ludo’.

Re: `guix pull` over HTTPS

[Ludovic Courtès]

Ricardo Wurmus  skribis:

> Leo Famulari  writes:
>
>> However, I think that pulling code over HTTPS using a certificate store
>> like nss-certs or from the host distro is a huge improvement over what
>> we have now. If we can do that sooner, we should.
>
> I agree.  If it’s easy to make the “le-certs” idea work I’m all for it,
> but I wouldn’t mind at all if we used nss-certs here.

Agreed, let’s improve things incrementally.

Thanks,
Ludo'.

Re: server and client in one package -> security issue (was: Add murmur)

[David Craven]

> And from my point of view Guix already has a medium problem of acceptance
> since it munges development-files and run-time files into one package - as we
> do for all libraries.

By development files I assume you mean header files? I don't see how those can
pose a security problem. Can you elaborate?

> Now if Guix starts munging server and client components into one
> package, this plain disqualifies GuixSD from any security sensitive
> system. [*]

> [*] OTOH it opens up chances for big business: selling "Secure GuixSD"
> to customers.

I think that we provide security on a best effort basis. A high profile target
like a bank or credit card payment service will likely have their own security
team and will use guixsd as a basis for their deployment. We can not do the
work that is the responsibility of an in house sysops team.

Re: server and client in one package -> security issue (was: Add murmur)

[ng0]

On 17-02-12 13:23:09, Hartmut Goebel wrote:
> Am 09.02.2017 um 23:50 schrieb Ludovic Courtès:
> > I think the only reason to separate things usually is size, not
> > “aesthetics.”  So I’d be in favor of keeping both in the same output if
> > there’s no size problem.
> 
> Separating clients and servers is not an "aesthetic" thing. It's a
> matter of security.
> 
> One basic rule for hardening systems is: "only install the required
> software". If we munge server and clients packages, this obeys this rule.
> 
> In my day-business I'm a security consultant (CISSP, CSSLP  and ISO
> 27001 Lead Implementer). And from my point of view Guix already has a
> medium problem of acceptance since it munges development-files and
> run-time files into one package - as we do for all libraries. This
> already contradicts the above mentioned basic rule.
> 
> Now if Guix starts munging server and client components into one
> package, this plain disqualifies GuixSD from any security sensitive
> system. [*]
> 
> [*] OTOH it opens up chances for big business: selling "Secure GuixSD"
> to customers.
> 
> -- 
> Regards
> Hartmut Goebel
> 
> | Hartmut Goebel  | h.goe...@crazy-compilers.com   |
> | www.crazy-compilers.com | compilers which you thought are impossible |
> 
> 

Exactly why I think we should do this, with a more detailed reasoning.
Thanks!
-- 
ng0 -- https://www.inventati.org/patternsinthechaos/

Re: Commits signed by key not registered on Savannah

[David Craven]

> Would the git repository, or a new git repository (guix-keys.git?) be a
> bad idea? Best case, we craft something which serves as an GNUPG_HOME
> for the keys which then live in the keyring of this thing (compare to
> gentoo-keys, debian-keys, etc).

I don't think that is a good idea. Placing it in the same git
repository that we are trying to verify means that if an ssh key has
been compromised, someone could add a malicious commit and a public
key - since this means that developers would be expected to manage
their own public keys in this list, it may not even be suspicious. If
someone MiM cuirass <-> savannah it would not even show in our view of
the repo.

The integrity of our source code is given by peer review - we are
subscribed to the commits ML so we see other peoples commits.

The most important thing is verifying that the substitutes come from
signed and verified commits only. Maybe keys need to be stored in the
cuirass configuration.

server and client in one package -> security issue (was: Add murmur)

[Hartmut Goebel]

Am 09.02.2017 um 23:50 schrieb Ludovic Courtès:
> I think the only reason to separate things usually is size, not
> “aesthetics.”  So I’d be in favor of keeping both in the same output if
> there’s no size problem.

Separating clients and servers is not an "aesthetic" thing. It's a
matter of security.

One basic rule for hardening systems is: "only install the required
software". If we munge server and clients packages, this obeys this rule.

In my day-business I'm a security consultant (CISSP, CSSLP  and ISO
27001 Lead Implementer). And from my point of view Guix already has a
medium problem of acceptance since it munges development-files and
run-time files into one package - as we do for all libraries. This
already contradicts the above mentioned basic rule.

Now if Guix starts munging server and client components into one
package, this plain disqualifies GuixSD from any security sensitive
system. [*]

[*] OTOH it opens up chances for big business: selling "Secure GuixSD"
to customers.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: Commits signed by key not registered on Savannah

[ng0]

On 17-02-12 00:41:38, David Craven wrote:
> > It might be nice to associate with each committer, a list of all keys
> > that they have ever used to sign commits in our git repository.
> 
> > Keys would be added to the list over time, but never removed.
> 
> Sounds good. Where would we put that list? And does that list also

Would the git repository, or a new git repository (guix-keys.git?) be a
bad idea? Best case, we craft something which serves as an GNUPG_HOME
for the keys which then live in the keyring of this thing (compare to
gentoo-keys, debian-keys, etc).

> need to be signed? Puh, lucky for me I don't have to be responsible
> for that key =P
> 
> For now my public keys are published on mit.edu, so they shouldn't be lost
> and can be retrieved when this list materializes.
> 
> >  The conventional usage of Savannah's ssh key registry is to include only
> > currently active keys, and that's needed as well.
> 
> I updated the key.
> 

-- 
ng0 -- https://www.inventati.org/patternsinthechaos/

Re: Debbugs handling of packages

[ng0]

On 17-02-08 20:15:46, Andreas Enge wrote:
> On Wed, Feb 08, 2017 at 03:29:31PM +0100, Ricardo Wurmus wrote:
> > Just a question: does this mean that patch *sets* should be flattened
> > before sending them so that they are part of the *same* debbugs issue
> > (instead of being scattered across as many issues as there are patches)?
> 
> This would be desirable, I think.
> 
> > E.g. for submitting the last 10 commits:
> > git format-patch -10 --stdout > series.patch
> > git send-email --to=guix-packa...@gnu.org series.patch
> 
> Alternatively, one can send only the first patch. This will open a new issue,
> and the submitter obtains the bug number with the corresponding e-mail
> address in reply. Then one can send the remaining patches message by message
> to this address.
> 
> Andreas

Okay, the mailman list is now live, I assume the debbugs part is fixed
too reading in the child threads here. We now have to reflect the
suggested use as described in this email in the contributing guide and
inform the help and devel list about this change.

Thanks,
--
ng0 -- https://www.inventati.org/patternsinthechaos/

[PATCH] gnu: Add font-google-material-design-icons.

[José Miguel Sánchez García]

--
José Miguel Sánchez GarcíaFrom 8b9659a427ef460d91a985a4d014bef05a0341d8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jos=C3=A9=20Miguel=20S=C3=A1nchez=20Garc=C3=ADa?=
 
Date: Sun, 12 Feb 2017 12:26:42 +0100
Subject: [PATCH] gnu: Add font-google-material-design-icons.

* gnu/packages/font.scm (font-google-material-design-icons): New
variable.
---
 gnu/packages/fonts.scm | 48 
 1 file changed, 48 insertions(+)

diff --git a/gnu/packages/fonts.scm b/gnu/packages/fonts.scm
index 43991d103..63f43786e 100644
--- a/gnu/packages/fonts.scm
+++ b/gnu/packages/fonts.scm
@@ -1031,3 +1031,51 @@ designed to work well in user interface environments.")
 "Font Awesome is a full suite of pictographic icons for easy scalable
 vector graphics.")
(license license:silofl1.1)))
+
+(define-public font-google-material-design-icons
+  (package
+   (name "font-google-material-design-icons")
+   (version "3.0.1")
+   (source (origin
+(method url-fetch)
+(uri (string-append
+   "https://github.com/google/material-design-icons/archive/";
+version ".tar.gz"))
+(sha256
+ (base32
+  "183n0qv3q8w6n27libarq1fhc4mqv2d3sasbfmbn7x9r5pw9c6ga"))
+(file-name (string-append name "-" version "-checkout"
+   (build-system trivial-build-system)
+   (native-inputs
+`(("tar" ,tar)
+  ("gzip" ,gzip)))
+   (arguments
+`(#:modules ((guix build utils))
+  #:builder (begin
+  (use-modules (guix build utils))
+  (let* ((font-dir (string-append %output
+  "/share/fonts/truetype"))
+ (source (assoc-ref %build-inputs "source"))
+ (font-filename "MaterialIcons-Regular.ttf")
+ (src-ttf-file (string-append "material-design-icons-"
+  ,version
+  "/iconfont/"
+  font-filename))
+ (dest-ttf-file (string-append font-dir font-filename))
+ (gzip (assoc-ref %build-inputs "gzip"))
+ (tar (assoc-ref %build-inputs "tar")))
+(setenv "PATH" (string-append gzip "/bin:"
+  tar "/bin:"))
+(system* "tar" "xf" source)
+(mkdir-p font-dir)
+(copy-file src-ttf-file dest-ttf-file)
+   (home-page "http://google.github.io/material-design-icons";)
+   (synopsis "Icon font of Google Material Design icons")
+   (description
+"Material design system icons are simple, modern, friendly, and sometimes
+quirky.  Each icon is created using our design guidelines to depict in simple
+and minimal forms the universal concepts used commonly throughout a UI.
+Ensuring readability and clarity at both large and small sizes, these icons
+have been optimized for beautiful display on all common platforms and display
+resolutions.")
+   (license license:silofl1.1)))
-- 
2.11.1

[PATCH] gnu: Add simh.

[José Miguel Sánchez García]

--
José Miguel Sánchez GarcíaFrom 1b3ed6f71861cc59493cde95171834139317b561 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jos=C3=A9=20Miguel=20S=C3=A1nchez=20Garc=C3=ADa?=
 
Date: Sun, 12 Feb 2017 12:33:49 +0100
Subject: [PATCH] gnu: Add simh.

* gnu/packages/simh.scm: New file.
* gnu/local.mk (GNU_SYSTEM_MODULES): Add simh.scm.
---
 gnu/local.mk  |  1 +
 gnu/packages/simh.scm | 96 +++
 2 files changed, 97 insertions(+)
 create mode 100644 gnu/packages/simh.scm

diff --git a/gnu/local.mk b/gnu/local.mk
index 63ce3af71..7da022a00 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -341,6 +341,7 @@ GNU_SYSTEM_MODULES =\
   %D%/packages/serveez.scm			\
   %D%/packages/shells.scm			\
   %D%/packages/shellutils.scm			\
+  %D%/packages/simh.scm\
   %D%/packages/skarnet.scm			\
   %D%/packages/skribilo.scm			\
   %D%/packages/slang.scm			\
diff --git a/gnu/packages/simh.scm b/gnu/packages/simh.scm
new file mode 100644
index 0..e424b44a0
--- /dev/null
+++ b/gnu/packages/simh.scm
@@ -0,0 +1,96 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2017 José Miguel Sánchez García 
+;;;
+;;; This file is part of GNU Guix.
+;;;
+;;; GNU Guix is free software; you can redistribute it and/or modify it
+;;; under the terms of the GNU General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; GNU Guix is distributed in the hope that it will be useful, but
+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;;; GNU General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU General Public License
+;;; along with GNU Guix.  If not, see .
+
+(define-module (gnu packages simh)
+  #:use-module ((guix licenses) #:prefix license:)
+  #:use-module (guix packages)
+  #:use-module (guix download)
+  #:use-module (guix build-system gnu)
+  #:use-module (gnu packages admin))
+
+(define-public simh
+  (package
+(name "simh")
+(version "3.9-0")
+(source (origin
+  (method url-fetch)
+  (uri (string-append "https://github.com/"; name "/" name
+  "/archive/v" version ".tar.gz"))
+  (sha256
+   (base32
+"1ymfy8j15d1aa4ai5xv9w7mk6lk4zx3zhfv0mfn66pdhrc8jlh0g"))
+  (file-name (string-append name "-" version "-checkout"
+(build-system gnu-build-system)
+(inputs
+ `(("libpcap" ,libpcap)))
+(arguments
+ '(#:tests? #f
+   #:make-flags (list
+  "LDFLAGS=-lm"
+  (string-append "INCPATH="
+ (assoc-ref %build-inputs "libpcap")
+ "/include")
+  (string-append "LIBPATH="
+ (assoc-ref %build-inputs "libpcap")
+ "/lib"))
+   #:phases
+ (modify-phases %standard-phases
+   (delete 'configure)
+   (add-before 'build 'prepare-build
+ (lambda _
+   (mkdir "BIN")))
+   (replace 'install
+ (lambda* (#:key outputs #:allow-other-keys)
+   (let* ((out (assoc-ref outputs "out"))
+  (bin (string-append out "/bin/"))
+  (lib (string-append out "/lib/simh/")))
+ (mkdir-p bin)
+ (mkdir-p lib)
+ (for-each
+   (lambda (file)
+ (copy-file file (string-append bin
+"simh-"
+(basename file
+   (find-files "BIN"))
+ (for-each
+   (lambda (file)
+ (copy-file file (string-append lib
+(basename file
+   (find-files "VAX" "bin$"
+(home-page "http://simh.trailing-edge.com";)
+(synopsis "Collection of simulators from The Computer History Simulation
+Project")
+(description
+ "SIMH is a highly portable, multi-system simulator.  SIMH implements
+simulators for:
+
+@itemize
+@item Data General Nova, Eclipse.
+@item Digital Equipment Corporation PDP-1, PDP-4, PDP-7, PDP-8, PDP-9, PDP-10,
+PDP-11, PDP-15, VAX.
+@item GRI Corporation GRI-909, GRI-99.
+@item IBM 1401, 1620, 1130, 7090/7094, System 3.
+@item Interdata (Perkin-Elmer) 16b and 32b systems.
+@item Hewlett-Packard 2114, 2115, 2116, 2100, 21MX, 1000.
+@item Honeywell H316/H516.
+@item MITS Altair 8800, with both 8080 and Z80.
+@item Royal-Mcbee LGP-30, LGP-21.
+@item Scientific Data Systems SDS 940.
+@item SWTP 6800.
+@end itemize")
+(license license:expat)))
-- 
2.11.1