Re: Gnome Flatpak build system, descriptions and questions

2016-08-26 Thread Shaun McCance
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

2016-08-26 Thread Bastien Nocera
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

2016-08-26 Thread Michael Catanzaro
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

2016-08-26 Thread Shaun McCance
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

2016-08-26 Thread Michael Catanzaro
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

2016-08-26 Thread Alexander Larsson
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

2016-08-26 Thread Bastien Nocera
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

2016-08-26 Thread Alexander Larsson
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

2016-08-26 Thread Michael Catanzaro
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

2016-08-26 Thread Alexander Larsson
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

2016-08-26 Thread Alexander Larsson
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