bug#22883: Trustable "guix pull"

[Werner Koch]

On Sun,  5 Jun 2016 00:27, l...@gnu.org said:

> cannot or shouldn’t try to guess what’s “best”, IMO.  So in this case,
> we keep the default names, ‘gpg2’ and ‘gpgv2’.
>
> Do you think we should rename those files?

Given that Guix is a new distro you should really try to get rid of 1.4
and only use 2.1.  For Windows we use the name "gpg" for a long time now
and there is a configure option --enable-gpg2-is-gpg to make it easier.

> We sign commits and it’s wonderful; now all we need is tools to actually
> use those signatures to authenticate checkouts.  :-)

Right - Although I sign my commits,e other GnuPG hackers don't do it,
and thus for me there is no strong need to verify the commits. But we
should have these tools.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
/* EFH in Erkrath: https://alt-hochdahl.de/haus */

bug#23697: guix system reconfigure hangs, shows repl in messages

[Jan Nieuwenhuizen]

Hi,

Not sure this qualifies as a bug, sending per request.

As a preparation to move from Debian to GuixSD, I have been dual
booting between Debian and GuixSD.

Using Debian as my main system with this layout

/dev/sda3 "debian" /
/dev/sda1  /guix
/dev/sda4  /home

I did

guix system init drakenvlieg.scm /guix

see attached, and then booted into GuixSD.  GuixSD still using its own
/home on its sda1 root.

On GuixSD, I ran Gnome and mounted the home I had been using with Debian

/dev/sda1 "guix"   /
/dev/sda3 "debian" /debian
/dev/sda4  /hoom<--manual mount

I set $HOME /to /hoom/janneke and checked that some things like wifi,
fonts, ssh, gnus, openvpn, touchpad etc. worked good enough to switch
over.

Then, I uncommented the /home section in drakenvlieg.scm, like so

;; Switch to GuixSD
(file-system (device "home")
 (title 'label)
 (mount-point "/home")
 (type "ext4"))
(file-system (device (label "Debian")) (title 'label) (mount-point 
"/debian") (type "ext4") (flags '(read-only)))

and (without considering I had mounted /hoom and set $HOME there) ran

guix system reconfigure drakenvlieg.scm

which eventually printed

...
guix system: loading new services: file-system-/home urandom-seed ntpd 
avahi-daemon ssh-daemon...
shepherd: Evaluating user expression (register-services (primitive-load 
"/gn...") ...).

In /var/log/messages I found some clue as to why this did not return

2016-06-01 19:55:20 Service root has been started.
2016-06-01 19:55:20 starting services...
2016-06-01 19:55:20 Service root-file-system has been started.
2016-06-01 19:55:20 waiting for udevd...
2016-06-01 19:55:23 Service udev has been started.
2016-06-01 19:55:23 Service swap-/dev/sda2 has been started.
2016-06-01 19:55:23 Service file-system-/sys/fs/cgroup has been started.
2016-06-01 19:55:23 Service file-system-/sys/fs/cgroup/hugetlb has been 
started.
2016-06-01 19:55:23 Service file-system-/sys/fs/cgroup/perf_event has been 
started.
2016-06-01 19:55:23 Service file-system-/sys/fs/cgroup/blkio has been 
started.
2016-06-01 19:55:23 Service file-system-/sys/fs/cgroup/freezer has been 
started.
2016-06-01 19:55:23 Service file-system-/sys/fs/cgroup/devices has been 
started.
2016-06-01 19:55:23 Service file-system-/sys/fs/cgroup/memory has been 
started.
2016-06-01 19:55:23 Service file-system-/sys/fs/cgroup/cpuacct has been 
started.
2016-06-01 19:55:23 Service file-system-/sys/fs/cgroup/cpu has been started.
2016-06-01 19:55:23 Service file-system-/sys/fs/cgroup/cpuset has been 
started.
2016-06-01 19:55:23 Service file-system-/sys/fs/cgroup/elogind has been 
started.
2016-06-01 19:55:23 Service file-system-/run/user has been started.
2016-06-01 19:55:23 Service file-system-/run/systemd has been started.
2016-06-01 19:55:23 Service file-system-/gnu/store has been started.
2016-06-01 19:55:23 Service file-system-/dev/shm has been started.
2016-06-01 19:55:23 Service file-system-/dev/pts has been started.
2016-06-01 19:55:23 Service user-file-systems has been started.
2016-06-01 19:55:23 Service user-processes has been started.
2016-06-01 19:55:23 Service host-name has been started.
2016-06-01 19:55:23 Service nscd has been started.
2016-06-01 19:55:23 Service guix-daemon has been started.
2016-06-01 19:55:23 Service syslogd has been started.
2016-06-01 19:55:23 Service loopback has been started.
2016-06-01 19:55:23 Service term-tty6 has been started.
2016-06-01 19:55:23 Service term-tty5 has been started.
2016-06-01 19:55:23 Service term-tty4 has been started.
2016-06-01 19:55:23 Service term-tty3 has been started.
2016-06-01 19:55:23 Service term-tty2 has been started.
2016-06-01 19:55:23 Service term-tty1 has been started.
2016-06-01 19:55:23 Service console-font-tty6 has been started.
2016-06-01 19:55:23 Service console-font-tty5 has been started.
2016-06-01 19:55:23 Service console-font-tty4 has been started.
2016-06-01 19:55:23 Service console-font-tty3 has been started.
2016-06-01 19:55:23 Service console-font-tty2 has been started.
2016-06-01 19:55:23 Service console-font-tty1 has been started.
2016-06-01 19:55:23 Service dbus-system has been started.
2016-06-01 19:55:23 Service networking has been started.
2016-06-01 19:55:23 Service ntpd has been started.
2016-06-01 19:55:23 Service upower-daemon has been started.
2016-06-01 19:55:23 Service avahi-daemon has been started.
2016-06-01 19:55:23 Service xorg-server has been started.
2016-06-01 19:55:23 Service postgres has been started.
2016-06-01 19:55:23 Service ssh-daemon has been started.
2016-06-01 19:55:23 Service console-keymap has been started.
2016-06-01 19:55:23 Respawning upower-daemon.
2016-06-01 19:55:23 Service upower-daemon

bug#22883: Authenticating a Git checkout

[Christopher Allan Webber]

Ludovic Courtès writes:

>>> Second, even if it did, it would be a shallow check: as Mike notes in
>>>  with the ‘signchk’
>>> script, you actually have to traverse the whole commit history and
>>> authenticate them one by one.  But that’s OK, it runs in presumably less
>>> than a minute on a repo the size of Guix’s, and we could also stop at
>>> signed tags to avoid redundant checks.
>>
>> Practically speaking, that's probably fine, though note that a signed
>> tag is just a signed hash of the commit it points to (with some
>> metadata), so you're trusting the integrity of SHA-1 and nothing
>> more.
>>
>> With that said, the tag points to what will hopefully be a signed
>> commit, so if you verify the signature of the tag _and_ that commit,
>> that'd be even better.  Git's use of SHA-1 makes cryptographic
>> assurances difficult/awkward.
>>
>> An occasional traversal of the entire DAG by, say, a CI script would
>> provide some pretty good confidence.  I wouldn't say it's necessary for
>> every pull.
>
> Agreed.

One theoretical optimization: if I verify the DAG, could I store
somewhere that I've verified from commit cabba6e and upward already, so
the next time I verify it only has to verify the new commits?

Mostly makes sense if we're already going down the only mildly
crazypants direction of implementing our own tooling :)

 - Chris

bug#23666: guix download fails for large files

[Andreas Enge]

Thanks for your suggestions, Leo and Ludovic! I still see this as a bug;
should I report it upstream to Nix?

On Wed, Jun 01, 2016 at 02:39:54PM +0200, Ludovic Courtès wrote:
> This is implemented using the ‘add-to-store’ RPC, which, after all these
> years, is still implemented like this (nix/libstore/local-store.cc):
> 
> --8<---cut here---start->8---
> Path LocalStore::addToStore(const string & name, const Path & _srcPath,
> bool recursive, HashType hashAlgo, PathFilter & filter, bool repair)
> {
> Path srcPath(absPath(_srcPath));
> debug(format("adding `%1%' to the store") % srcPath);
> 
> /* Read the whole path into memory. This is not a very scalable
>method for very large paths, but `copyPath' is mainly used for
>small files. */
> --8<---cut here---end--->8---

Something that mainly does not fail could indeed be seen as a bug...
But how come that "guix download http://"; succeeds, where
"guix download file://" fails?

Andreas

bug#22883: Authenticating a Git checkout

[Leo Famulari]

On Sun, Jun 05, 2016 at 03:39:04PM -0500, Christopher Allan Webber wrote:
> One theoretical optimization: if I verify the DAG, could I store
> somewhere that I've verified from commit cabba6e and upward already, so
> the next time I verify it only has to verify the new commits?

AIUI `git verify-commit` takes a single commit as an argument, so you
can pass it an argument like this:

$ git verify-commit $(git rev-list deadbeef..cabba6e)

... and it will only look at those. So, you would tailor the range of
commits that you want to verify.

> Mostly makes sense if we're already going down the only mildly
> crazypants direction of implementing our own tooling :)

It seems you'd want a tool that you trust to store a reference to the
latest commit you trust, and use it to create the range of commits you
pass to `git rev-list`.

bug#22883: Authenticating a Git checkout

[Mike Gerwitz]

On Sun, Jun 05, 2016 at 15:39:04 -0500, Christopher Allan Webber wrote:
> One theoretical optimization: if I verify the DAG, could I store
> somewhere that I've verified from commit cabba6e and upward already, so
> the next time I verify it only has to verify the new commits?

tbh, I haven't given this the amount of thought/research that I feel it
needs.  Unfortunately, you got me thinking, so here's another long
message.

In essence, this is equivalent to Ludo's suggestion of stopping at
the last tag (if you envision, say, tagging the last processed commit)
_provided that_ you also verify the commit that the tag is pointing to.

My short answer is: practically speaking, it's probably fine, because
you're more than likely trying to defend against an attacker that gains
access to the repo, not a second-preimage attack.

*   *
  *

Long answer (braindump):

When I consider the potential threats, I consider that the integrity of
each blob, tree, commit, etc are fairly well assured by their hashes,
but depend entirely on the security of SHA-1, whose future is
increasingly grim.  SHA-1 does just fine for uniquely identifying
objects---and if it didn't, hashes offending preimages would just be
blacklisted.  But it was never intended for security.

The problem is pretty bad: signed commits will ensure the integrity of
the commit itself (the object---as in `git cat-file -p COMMIT`); the
problem is that you don't just have to find a preimage for the hashes
signed in that commit: the tree hash is what really dictates the
content, and that tree hash in turn identifies other trees and blobs:

  $ git cat-file -p 'HEAD^{tree}'
  ...
  100644 blob 9b9481deea8cee4cc61971a752d02c04d5f0654econfigure.ac
  04 tree f2b4528e1f66f3bbc4742dc4a11bd1283cd475b9doc
  ...

That blob contains the actual file contents.

So in a large project like Guix, you have so many opportunities!  You
can try to find preimages for any of the trees or blobs _without having
to worry about any signatures_; neither trees nor blobs are signed.

With that said, if I recall correctly (and after a very brief glance at
fetch-pack.c), a successful preimage attack would only affect users who
haven't already fetched the legitimate object---otherwise Git wouldn't
bother fetching it.  I'm not sure if I find comfort in this or not: it's
been used by some to dismiss the problem of collisions, but (assuming
git is silent about it---and why wouldn't it be, as it wouldn't know
better) that's worse, since maintainers and common contributors wouldn't
notice anything wrong at all.  But someone who clones fresh and compiles
would be screwed.

So signing commits almost certainly protects you against someone who
gains access to the repository on a common origin or a
maintainer/contributor's PC, provided that nobody's private key is
compromised.

But there doesn't seem to be any way to secure a git repository against
a second-preimage attack.

So given that, it doesn't really matter if you re-verify all the commits
or not: an attacker doesn't need to even bother with the commit
object.  I guess one option is to keep a local copy of the repository,
clone a fresh copy, and occasionally diff _every_ object (commit, tag,
tree, blob) for differences.

So if Git wants to take this issue seriously, changes have to be
made.  In the meantime, in addition to commit verification, you can
always keep around a local copy of the repository, always clone a copy,
and ensure that builds between the two are reproducible.


signature.asc
Description: PGP signature