Re: Gnome.org's crypto infrastructure
Hi, > I think the opposite is true as well, in that some software needs > other frameworks in place to do "distcheck" rather than "check" -- for > instance colord needs a running colord daemon to test against. Other > software needs X. Well, maybe it could do it in a gnome-continuous VM or something like that. --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome.org's crypto infrastructure
On 8 July 2014 13:24, Ray Strode wrote: > 1) tarballs would be generated with a standardized set of autotools, > instead of whatever the maintainer happens to have installed I think the opposite is true as well, in that some software needs other frameworks in place to do "distcheck" rather than "check" -- for instance colord needs a running colord daemon to test against. Other software needs X. Workaroundable, and I totally think something better than scp'ing tarballs would be good. Richard. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome.org's crypto infrastructure
Hi, > * GNOME releases tarballs of source code. Maintainers regularly post > checksums of their tarballs along with their announcement emails. Until > now, I'm not sure if we have had the need to *guarantee* that a > particular release of code is authentic. For example, we don't actually > crypto-sign tarballs like the Tor project would --- in their case, > whoever downloads the code *really* wants to ensure that it hasn't been > tampered with. Again, I'm not sure if we have such kind of > security-conscious code, but maybe we could start crypto-signing our > tarballs. Which brings me to... One thing that would be really neat (imo) is if instead of maintainers pushing tarballs to master.gnome.org and running ftpadmin manually, they instead pushed a "git-tag -s" GPG signed tag of a specific naming scheme (maybe an rc suffix, e.g., "3.13.4-rc1"), and then an automated release-team VM would notice the tag, check out the tarball, run "make distcheck" and if it all passed muster, push a final tag (e.g., "3.13.4") signed with a release-team key, and then push the tarball to master.gnome.org. A few downsides: 1) make distcheck often fails, and this model sort of encourages maintainers to "fire-and-forget" when making a release instead of baby sitting it to the end 2) The system would have to be implemented, and it's a non-trivial amount of work to implement 3) It might mean keeping a release-team private key with no password on a VM connected directly to the internet. a few upsides: 1) tarballs would be generated with a standardized set of autotools, instead of whatever the maintainer happens to have installed 2) "make distcheck" would be run on a fresh checkout of the source, so it would eliminate a failure mode where some left over bits in the maintainers working tree made things work even when the pushed git tree itself is missing files. 3) all the tarballs would be signed with an "official" key --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome.org's crypto infrastructure
Hey Federico, Federico Mena Quintero wrote: ... > This mail is intended for brainstorming some ideas before GUADEC. It's > not to decide anything and set it in stone. ... There's a GSoC project that's focusing on keysigning this summer - https://www.google-melange.com/gsoc/project/details/google/gsoc2014/andreimg/5766466041282560 Could be relevant... Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Gnome.org's crypto infrastructure
Hi, all, This mail is intended for brainstorming some ideas before GUADEC. It's not to decide anything and set it in stone. I've been preparing my GUADEC talk about crypto infrastructure for newbies, and I've started to realize that it may be useful for gnome.org to have an "official", publicly-documented crypto infrastructure of its own. Here is a set of somewhat related ideas: * GNOME releases tarballs of source code. Maintainers regularly post checksums of their tarballs along with their announcement emails. Until now, I'm not sure if we have had the need to *guarantee* that a particular release of code is authentic. For example, we don't actually crypto-sign tarballs like the Tor project would --- in their case, whoever downloads the code *really* wants to ensure that it hasn't been tampered with. Again, I'm not sure if we have such kind of security-conscious code, but maybe we could start crypto-signing our tarballs. Which brings me to... * Identity in the GNOME project. We have keysigning parties at GUADEC. Some maintainers actually sign their tarball announcement emails, so if you have their GPG public key (and if they posted a checksum of their tarball in their email), you can actually verify whether a tarball is pristine. I doubt that anyone actually does this sort of checking ;) * If we ever get an infrastructure to publish compiled "apps", what with all the sandboxing stuff being worked on, will we need harder guarantees about authentic binaries and code? * Would it be useful / trustworthy to have a gnome.org-specific GPG keyserver? One that cannot be poisoned like public keyservers? (I don't really know how to do this, but if only people with SSH keys can push to git.gnome.org, maybe we can do something similar for a keyserver...). * Would app authors need certificates? Should gnome.org be able to issue certificates (and should we ship our Certificate Authority information somewhere)? * Can we have some sort of synergy with keybase.io? * There is a public key in the keyservers for secr...@gnome.org, but as far as I can tell it has no signatures. How would people verify it? (AFAICT it was announced here: https://mail.gnome.org/archives/infrastructure-announce/2013-November/msg1.html) * Should we have a web page linking to GNOME's important public keys and such? (The ones you would use to encrypt reports of security bugs and such.) * (I know Debian has well-documented procedures for signing things and such; I'm sure we can copy those procedures for some things.) Again, these are just questions or ideas for now. Any input is appreciated. All the (conflicting) information about crypto-related matters out there on the web is giving me the biggest case of impostor syndrome ever :) Federico ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
