Re: .gitignore

> On 10 Aug 2015 08:28, Justin (jlec) wrote:
> > how do we maintain this file?
>
> like any other file. git add && git commit.
>
> > I like to propose to add the md5-cache into it. Which other files are of interest?
>
> /distfiles/
> /local/
> /packages/

Those directories should not be ignored. Those should not exist for
a long time.

Re: .gitignore

On 8/10/15 3:35 AM, Justin (jlec) wrote:

> On 10/08/15 08:42, Mike Frysinger wrote:
>> On 10 Aug 2015 08:28, Justin (jlec) wrote:
>>> how do we maintain this file?
>> like any other file. git add && git commit.
>>
> I rather meant, if this file should only be modified after a discussion in a bug
> or on a ml. Or if only QA is modifying this file. Or if anybody can play around
> as she/he likes.
>
> Justin
>
>

That's how I interpreted your original question. I think we should
discuss modifying .gitignore on this list, along with any other far
reaching changes which individual committers can make to git. (Can't
think of another example right now, but there probably is.)

Re: .gitignore

> On 10 Aug 2015 08:28, Justin (jlec) wrote:
>> how do we maintain this file?
>
> like any other file. git add && git commit.
>
>> I like to propose to add the md5-cache into it. Which other files are of interest?
>
> /distfiles/
> /local/
> /packages/
>
> /metadata/md5-cache/
> -mike

Expanding on this: the rsync master creates the following
files/directories under metatdata. On my own system, I like to symlink
them to locations outside my repo so that related portage features
continue to work.

I would like to have these added in .gitignore.

metadata/dtd/ # used by something?
metadata/glsa/ # used by the GLSA utilities?
matadata/herds.xml # used by equery from gentoolkit
metadata/news/ # used by eselect news

Re: .gitignore

>
> Expanding on this: the rsync master creates the following
> files/directories under metatdata. On my own system, I like to symlink
> them to locations outside my repo so that related portage features
> continue to work.
>
> I would like to have these added in .gitignore.
>
> metadata/dtd/ # used by something?
> metadata/glsa/ # used by the GLSA utilities?
> matadata/herds.xml # used by equery from gentoolkit
> metadata/news/ # used by eselect news
>

As a side note, it probably wouldn't hurt to set up a guide for
running git on /usr/portage, including setting up these symlinks,
running egencache after emerge --sync, etc. I imagine that this is a
configuration that many developers will tend to use, and with the
advent of git we may see more users who tend to contribute doing the
same.

Re: .gitignore

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 08/10/2015 08:09 AM, Rich Freeman wrote:

> On Mon, Aug 10, 2015 at 11:04 AM, Mike Gilbert <[hidden email]>
> wrote:
>>
>> Expanding on this: the rsync master creates the following
>> files/directories under metatdata. On my own system, I like to
>> symlink them to locations outside my repo so that related portage
>> features continue to work.
>>
>> I would like to have these added in .gitignore.
>>
>> metadata/dtd/ # used by something? metadata/glsa/ # used by the
>> GLSA utilities? matadata/herds.xml # used by equery from
>> gentoolkit metadata/news/ # used by eselect news
>>
>
> As a side note, it probably wouldn't hurt to set up a guide for
> running git on /usr/portage, including setting up these symlinks,
> running egencache after emerge --sync, etc. I imagine that this is
> a configuration that many developers will tend to use, and with
> the advent of git we may see more users who tend to contribute
> doing the same.
>

Re: .gitignore

> On Mon, Aug 10, 2015 at 2:42 AM, Mike Frysinger <[hidden email]> wrote:
>> On 10 Aug 2015 08:28, Justin (jlec) wrote:
>>> how do we maintain this file?
>>
>> like any other file. git add && git commit.
>>
>>> I like to propose to add the md5-cache into it. Which other files are of interest?
>>
>> /distfiles/
>> /local/
>> /packages/
>>
>> /metadata/md5-cache/
>> -mike
>
> Expanding on this: the rsync master creates the following
> files/directories under metatdata. On my own system, I like to symlink
> them to locations outside my repo so that related portage features
> continue to work.
>
> I would like to have these added in .gitignore.
>
> metadata/dtd/ # used by something?
> metadata/glsa/ # used by the GLSA utilities?
> matadata/herds.xml # used by equery from gentoolkit
> metadata/news/ # used by eselect news

Heh, Robin has already taken care of these. I did not notice the
.gitignore file in the metadata subdirectory.

rsync mirror security (WAS: Re: [gentoo-dev] .gitignore)

> On Mon, Aug 10, 2015 at 11:04 AM, Mike Gilbert <[hidden email]> wrote:
>>
>> Expanding on this: the rsync master creates the following
>> files/directories under metatdata. On my own system, I like to symlink
>> them to locations outside my repo so that related portage features
>> continue to work.
>>
>> I would like to have these added in .gitignore.
>>
>> metadata/dtd/ # used by something?
>> metadata/glsa/ # used by the GLSA utilities?
>> matadata/herds.xml # used by equery from gentoolkit
>> metadata/news/ # used by eselect news
>>
>
> As a side note, it probably wouldn't hurt to set up a guide for
> running git on /usr/portage, including setting up these symlinks,
> running egencache after emerge --sync, etc. I imagine that this is a
> configuration that many developers will tend to use, and with the
> advent of git we may see more users who tend to contribute doing the
> same.
>

In fact, this should be the recommended way of running gentoo for
everyone. Our rsync methods are still inherently insecure (unless I
missed something), because:
1. machine key
2. profiles, eclasses and so on are not covered with a
signature/Manifest anyway

Re: rsync mirror security (WAS: Re: [gentoo-dev] .gitignore)

On Mon, 10 Aug 2015 22:13:23 +0200 hasufell wrote:

> On 08/10/2015 05:09 PM, Rich Freeman wrote:
> > On Mon, Aug 10, 2015 at 11:04 AM, Mike Gilbert <[hidden email]> wrote:
> >>
> >> Expanding on this: the rsync master creates the following
> >> files/directories under metatdata. On my own system, I like to symlink
> >> them to locations outside my repo so that related portage features
> >> continue to work.
> >>
> >> I would like to have these added in .gitignore.
> >>
> >> metadata/dtd/ # used by something?
> >> metadata/glsa/ # used by the GLSA utilities?
> >> matadata/herds.xml # used by equery from gentoolkit
> >> metadata/news/ # used by eselect news
> >>
> >
> > As a side note, it probably wouldn't hurt to set up a guide for
> > running git on /usr/portage, including setting up these symlinks,
> > running egencache after emerge --sync, etc. I imagine that this is a
> > configuration that many developers will tend to use, and with the
> > advent of git we may see more users who tend to contribute doing the
> > same.
> >
>
> In fact, this should be the recommended way of running gentoo for
> everyone. Our rsync methods are still inherently insecure (unless I
> missed something), because:
> 1. machine key
> 2. profiles, eclasses and so on are not covered with a
> signature/Manifest anyway

Not unless metadata cache will be synced too from a trusted source.
It takes too much time to generate, especially on non-brand-new
hardware.

Re: rsync mirror security (WAS: Re: [gentoo-dev] .gitignore)

On Mon, 10 Aug 2015 23:47:21 +0300 Andrew Savchenko wrote:

> On Mon, 10 Aug 2015 22:13:23 +0200 hasufell wrote:
> > On 08/10/2015 05:09 PM, Rich Freeman wrote:
> > > On Mon, Aug 10, 2015 at 11:04 AM, Mike Gilbert <[hidden email]> wrote:
> > >>
> > >> Expanding on this: the rsync master creates the following
> > >> files/directories under metatdata. On my own system, I like to symlink
> > >> them to locations outside my repo so that related portage features
> > >> continue to work.
> > >>
> > >> I would like to have these added in .gitignore.
> > >>
> > >> metadata/dtd/ # used by something?
> > >> metadata/glsa/ # used by the GLSA utilities?
> > >> matadata/herds.xml # used by equery from gentoolkit
> > >> metadata/news/ # used by eselect news
> > >>
> > >
> > > As a side note, it probably wouldn't hurt to set up a guide for
> > > running git on /usr/portage, including setting up these symlinks,
> > > running egencache after emerge --sync, etc. I imagine that this is a
> > > configuration that many developers will tend to use, and with the
> > > advent of git we may see more users who tend to contribute doing the
> > > same.
> > >
> >
> > In fact, this should be the recommended way of running gentoo for
> > everyone. Our rsync methods are still inherently insecure (unless I
> > missed something), because:
> > 1. machine key
> > 2. profiles, eclasses and so on are not covered with a
> > signature/Manifest anyway
>
> Not unless metadata cache will be synced too from a trusted source.
> It takes too much time to generate, especially on non-brand-new
> hardware.

Another issue: we will have to setup git mirrors as well (probably
reusing hosts providing rsync mirrors). I really doubt current
infrastructure will survive if all users will sync from its git.

Re: rsync mirror security (WAS: Re: [gentoo-dev] .gitignore)

> On Mon, 10 Aug 2015 22:13:23 +0200 hasufell wrote:
>> On 08/10/2015 05:09 PM, Rich Freeman wrote:
>>> On Mon, Aug 10, 2015 at 11:04 AM, Mike Gilbert <[hidden email]> wrote:
>>>>
>>>> Expanding on this: the rsync master creates the following
>>>> files/directories under metatdata. On my own system, I like to symlink
>>>> them to locations outside my repo so that related portage features
>>>> continue to work.
>>>>
>>>> I would like to have these added in .gitignore.
>>>>
>>>> metadata/dtd/ # used by something?
>>>> metadata/glsa/ # used by the GLSA utilities?
>>>> matadata/herds.xml # used by equery from gentoolkit
>>>> metadata/news/ # used by eselect news
>>>>
>>>
>>> As a side note, it probably wouldn't hurt to set up a guide for
>>> running git on /usr/portage, including setting up these symlinks,
>>> running egencache after emerge --sync, etc. I imagine that this is a
>>> configuration that many developers will tend to use, and with the
>>> advent of git we may see more users who tend to contribute doing the
>>> same.
>>>
>>
>> In fact, this should be the recommended way of running gentoo for
>> everyone. Our rsync methods are still inherently insecure (unless I
>> missed something), because:
>> 1. machine key
>> 2. profiles, eclasses and so on are not covered with a
>> signature/Manifest anyway
>
> Not unless metadata cache will be synced too from a trusted source.
> It takes too much time to generate, especially on non-brand-new
> hardware.
>

I was wondering if that could be automated in a separate branch (only
needs to update in 24h intervals).

Re: rsync mirror security (WAS: Re: [gentoo-dev] .gitignore)

On 2015-08-10 23:49, Andrew Savchenko wrote:
> Another issue: we will have to setup git mirrors as well (probably
> reusing hosts providing rsync mirrors). I really doubt current
> infrastructure will survive if all users will sync from its git.

Re: rsync mirror security (WAS: Re: [gentoo-dev] .gitignore)

> On Mon, 10 Aug 2015 22:13:23 +0200 hasufell wrote:
> > On 08/10/2015 05:09 PM, Rich Freeman wrote:
> > > On Mon, Aug 10, 2015 at 11:04 AM, Mike Gilbert <[hidden email]> wrote:
> > >>
> > >> Expanding on this: the rsync master creates the following
> > >> files/directories under metatdata. On my own system, I like to symlink
> > >> them to locations outside my repo so that related portage features
> > >> continue to work.
> > >>
> > >> I would like to have these added in .gitignore.
> > >>
> > >> metadata/dtd/ # used by something?
> > >> metadata/glsa/ # used by the GLSA utilities?
> > >> matadata/herds.xml # used by equery from gentoolkit
> > >> metadata/news/ # used by eselect news
> > >>
> > >
> > > As a side note, it probably wouldn't hurt to set up a guide for
> > > running git on /usr/portage, including setting up these symlinks,
> > > running egencache after emerge --sync, etc. I imagine that this is a
> > > configuration that many developers will tend to use, and with the
> > > advent of git we may see more users who tend to contribute doing the
> > > same.
> > >
> >
> > In fact, this should be the recommended way of running gentoo for
> > everyone. Our rsync methods are still inherently insecure (unless I
> > missed something), because:
> > 1. machine key
> > 2. profiles, eclasses and so on are not covered with a
> > signature/Manifest anyway
>
> Not unless metadata cache will be synced too from a trusted source.
> It takes too much time to generate, especially on non-brand-new
> hardware.

Err, it takes around 2 minutes to generate full cache with pkgcore on
some old Xeon. Updates are much faster.

Re: rsync mirror security

We could also provide automatic signed tags every 30min/1h/2h/whatever
(signed with a suitable infrastructure key). With that, the integrity of
a tagged git checkout can be easily verified on client side.

Re: rsync mirror security

On 10 Aug 2015 16:05, Matthias Maier wrote:
> > Users can fetch/pull from Github.
>
> We could also provide automatic signed tags every 30min/1h/2h/whatever
> (signed with a suitable infrastructure key). With that, the integrity of
> a tagged git checkout can be easily verified on client side.

it would have to re-use the same tag name every time otherwise we end up with
17.5k/8.7k/4.3k/whatever new tags per year ... a really bad idea

depending on how fast the process is, it could just be part of the receive hook
on the server that does the checking now. that way the tag is always up to date
with every push a developer makes.
-mike

Re: rsync mirror security

On 11 August 2015 at 09:05, Matthias Maier <[hidden email]> wrote:
> We could also provide automatic signed tags every 30min/1h/2h/whatever
> (signed with a suitable infrastructure key). With that, the integrity of
> a tagged git checkout can be easily verified on client side.

I'm distinctly under the impression that a signed tag doesn't really
give you anything a signed commit wouldn't.

That is, I was under the impression signing a tag only signs the
references themselves, and then relies on SHA1 referential integrity
beyond that.

Hence, a signed tag basically is a statement proving X author
authorized Y-SHA1, and then it subsequently implies that X author
authorized whatever Y-SHA1 refers to.

So adding additional tags *just* for the purpose of having a periodic
signature would give no benefit over the "all tags are signed, all
commits are signed" mechanism for git users, and the signed tag could
_not_ be verified against an RSYNC clone.