Re: Gnome Flatpak build system, descriptions and questions
On Fri, 2016-08-26 at 11:21 -0500, Michael Catanzaro wrote: > On Fri, 2016-08-26 at 11:48 -0400, Shaun McCance wrote: > > > > IIRC, git.gnome.org won't let you push an unsigned tag. > I've been doing it for a while, so it most certainly does! I don't > see > value in signing our tags as (a) clearly nobody is checking the > signatures, and (b) we don't currently have any centralized registry > of > trusted keys, so it's not possible to know which signatures to trust > anyway. Ah, it appears an annotated tag is sufficient: https://wiki.gnome.org/Git/Help/LightweightTags https://git.gnome.org/browse/sysadmin-bin/tree/git/pre-receive-check-po licy#n185 > On Fri, 2016-08-26 at 11:48 -0400, Shaun McCance wrote: > > > > > > That still leaves the question: If the release team tags with a key > > we > > can all trust, how does the release team trust that the commit they > > tagged is the one the maintainer intended? > We don't actually use git tags for anything official; we work with > tarballs hosted on download.gnome.org. If we want to switch to using > signed git tags instead of tarballs, I think that'd be fine, but it > would require a lot of infrastructure work. I may have misread what Alex was asking for. I'll just shut up now and let the release team and Alex figure out what's best. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome Flatpak build system, descriptions and questions
On Fri, 2016-08-26 at 11:48 -0400, Shaun McCance wrote: > On Fri, 2016-08-26 at 10:17 -0500, Michael Catanzaro wrote: > > On Fri, 2016-08-26 at 10:29 -0400, Shaun McCance wrote: > > > > > > Don't all maintainers already use signed tags for releases? > > No. I used to do this, but stopped a couple years ago because it > > was > > pointless. Nobody should trust my key, so why use it? > > IIRC, git.gnome.org won't let you push an unsigned tag. Not sure whether we're talking about the same thing, but I never signed any tags, or releases for GNOME. > I've been > tagging releases since the days of CVS, because tags are useful. I > thought everybody did. > > That still leaves the question: If the release team tags with a key > we > can all trust, how does the release team trust that the commit they > tagged is the one the maintainer intended? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome Flatpak build system, descriptions and questions
On Fri, 2016-08-26 at 11:48 -0400, Shaun McCance wrote: > IIRC, git.gnome.org won't let you push an unsigned tag. I've been doing it for a while, so it most certainly does! I don't see value in signing our tags as (a) clearly nobody is checking the signatures, and (b) we don't currently have any centralized registry of trusted keys, so it's not possible to know which signatures to trust anyway. On Fri, 2016-08-26 at 11:48 -0400, Shaun McCance wrote: > > That still leaves the question: If the release team tags with a key > we > can all trust, how does the release team trust that the commit they > tagged is the one the maintainer intended? We don't actually use git tags for anything official; we work with tarballs hosted on download.gnome.org. If we want to switch to using signed git tags instead of tarballs, I think that'd be fine, but it would require a lot of infrastructure work. Michael ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome Flatpak build system, descriptions and questions
On Fri, 2016-08-26 at 10:17 -0500, Michael Catanzaro wrote: > On Fri, 2016-08-26 at 10:29 -0400, Shaun McCance wrote: > > > > Don't all maintainers already use signed tags for releases? > No. I used to do this, but stopped a couple years ago because it was > pointless. Nobody should trust my key, so why use it? IIRC, git.gnome.org won't let you push an unsigned tag. I've been tagging releases since the days of CVS, because tags are useful. I thought everybody did. That still leaves the question: If the release team tags with a key we can all trust, how does the release team trust that the commit they tagged is the one the maintainer intended? -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome Flatpak build system, descriptions and questions
On Fri, 2016-08-26 at 10:29 -0400, Shaun McCance wrote: > Don't all maintainers already use signed tags for releases? No. I used to do this, but stopped a couple years ago because it was pointless. Nobody should trust my key, so why use it? Michael ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome Flatpak build system, descriptions and questions
On fre, 2016-08-26 at 13:39 +0200, Bastien Nocera wrote: > On Fri, 2016-08-26 at 09:43 +0200, Alexander Larsson wrote: > > > > Anyway, the best we can do now is i think having a git repo, say > > gnome- > > apps-nightly, that has two files in it, listing for each row: > > * A git repo > > * A branch name > > * The filename of the json manifest in the repo > > One of the files would be for unstable/nightly builds, and the > > other > > for stable builds. > You can replace all 3 of those items with a URL pointing to the file > in > an https cgit. That only works if the .json file doesn't come with more files though. Patches or whatnot. We would list those as urls too i guess, but then things aren't as nice. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's an oversexed voodoo messiah with nothing left to lose. She's a transdimensional bisexual doctor with the power to see death. They fight crime! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome Flatpak build system, descriptions and questions
On Fri, 2016-08-26 at 09:43 +0200, Alexander Larsson wrote: > On tor, 2016-08-25 at 17:29 +0100, Richard Hughes wrote: > > On 25 August 2016 at 16:29, Alexander Larsson> > wrote: > > > > > > However, it would > > > make more sense for each individual application developers to > > > maintain > > > the manifest in the applications git repo. > > I think this is a very good idea indeed; I was confused about the > > "centralization" aspect of the builder files. Isn't this just some > > globbing, if we all agree to put the manifest in the same place in > > the > > git tree? > > Well, it was initially put in a separate git repo as we were just a > few > people trying to build a lot of apps, and that was the easiest way to > get started. However, now that things are a bit more stable moving it > to each individual repo makes sense. > > There are some complexities though. There are two things we want to > build, the "latest unstable" and the "last stable release". The > obvious > solution is to store a json file with a predictable name in master > for > the unstable release, and in the latest stable branch for the stable > one. > > However, how do we find which git repos have such json files, and how > do we know what is the current latest stable branch? Also, its > somewhat > weird to clone the entire git repo just to get a json file that then > itself may refer to the git repo. > > Another issue is that we'd like the to have some control of what gets > built, at least for the stable builds. Right now we just pull the > gnome-apps-nightly repo and assumes it is correct (i.e nobody > commited > an attack to git or MITMed our connection to git.gnome.org), but from > there everything is verified by sha256 on all the various tarballs > that > are downloaded. Getting even this level of verification is trickier > when things are spread all across git.gnome.org. Ideally we should > have > some kind of gpg signatures for the stable commits so that we can > verify everything from that, but we don't really have that kind of > setup for gnome git. > > Anyway, the best we can do now is i think having a git repo, say > gnome- > apps-nightly, that has two files in it, listing for each row: > * A git repo > * A branch name > * The filename of the json manifest in the repo > One of the files would be for unstable/nightly builds, and the other > for stable builds. You can replace all 3 of those items with a URL pointing to the file in an https cgit. 2 problems with requiring GPG signatures for stable releases though: - gnupg's "UI" sucks utterly - we really should have had people signing each other's keys at GUADEC when face to face ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome Flatpak build system, descriptions and questions
On fre, 2016-08-26 at 05:02 -0500, Michael Catanzaro wrote: > Clone via https:// rather than using git:// Does git verify signatures for this? That avoids the MITM attack i guess. Still, I would like us to eventually have a setup where every stable release of every gnome module has a GPG signed commit, put there by the release team. Then we could make sure that the binaries for stable builds are the proper releases. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a scarfaced playboy filmmaker for the 21st century. She's a scantily clad impetuous mercenary who inherited a spooky stately manor from her late maiden aunt. They fight crime! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome Flatpak build system, descriptions and questions
On Fri, 2016-08-26 at 09:43 +0200, Alexander Larsson wrote: > i.e nobody [...] MITMed our connection to git.gnome.org Clone via https:// rather than using git:// ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome Flatpak build system, descriptions and questions
On tor, 2016-08-25 at 17:29 +0100, Richard Hughes wrote: > On 25 August 2016 at 16:29, Alexander Larsson> wrote: > > > > However, it would > > make more sense for each individual application developers to > > maintain > > the manifest in the applications git repo. > I think this is a very good idea indeed; I was confused about the > "centralization" aspect of the builder files. Isn't this just some > globbing, if we all agree to put the manifest in the same place in > the > git tree? Well, it was initially put in a separate git repo as we were just a few people trying to build a lot of apps, and that was the easiest way to get started. However, now that things are a bit more stable moving it to each individual repo makes sense. There are some complexities though. There are two things we want to build, the "latest unstable" and the "last stable release". The obvious solution is to store a json file with a predictable name in master for the unstable release, and in the latest stable branch for the stable one. However, how do we find which git repos have such json files, and how do we know what is the current latest stable branch? Also, its somewhat weird to clone the entire git repo just to get a json file that then itself may refer to the git repo. Another issue is that we'd like the to have some control of what gets built, at least for the stable builds. Right now we just pull the gnome-apps-nightly repo and assumes it is correct (i.e nobody commited an attack to git or MITMed our connection to git.gnome.org), but from there everything is verified by sha256 on all the various tarballs that are downloaded. Getting even this level of verification is trickier when things are spread all across git.gnome.org. Ideally we should have some kind of gpg signatures for the stable commits so that we can verify everything from that, but we don't really have that kind of setup for gnome git. Anyway, the best we can do now is i think having a git repo, say gnome- apps-nightly, that has two files in it, listing for each row: * A git repo * A branch name * The filename of the json manifest in the repo One of the files would be for unstable/nightly builds, and the other for stable builds. Then we can make the build scripts check out each of these repos and build them. Maintainers can then maintain the manifests in their own git repos, but will have to commit to gnome-apps-nightly when they add a new app, or change to a new stable branch. Does that make sense? -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a globe-trotting Catholic dwarf possessed of the uncanny powers of an insect. She's a provocative out-of-work bounty hunter with the power to see death. They fight crime! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome Flatpak build system, descriptions and questions
On tor, 2016-08-25 at 17:12 +0100, Alberto Ruiz wrote: > > > 2016-08-25 16:29 GMT+01:00 Alexander Larsson: > > After some work I now have the gnome runtimes and applications > > building again, now on the new gnome build infrastructure. > > > > We no have these nuild machines: > > > > sdkbuilder1.gnome.org - x86_64 & i386, stable & nightly > > gnome5.codethink.co.uk - aarch64, nightly > > gnome6.codethink.co.uk - aarch64, stable > > gnome7.codethink.co.uk - arm, nightly > > gnome8.codethink.co.uk - arm, stable > > > > The first one is a VM that us running in the gnome infrastructure, > > and > > the rest are aarch64 blades that collabora are running for the > > Gnome > > project. > Perhaps you meant Codethink? Yeah, obviously. Sorry about that. Too many Co* companies :) -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's an all-American voodoo firefighter with a winning smile and a way with the ladies. She's a warm-hearted French-Canadian traffic cop from Mars. They fight crime! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list