.gitignore

classic Classic list List threaded Threaded
57 messages Options
123
Reply | Threaded
Open this post in threaded view
|

.gitignore

Justin Lecher (jlec)
Hi,

how do we maintain this file?

I like to propose to add the md5-cache into it. Which other files are of interest?

Justin


signature.asc (970 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: .gitignore

Mike Frysinger
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

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: .gitignore

Michał Górny-5
Dnia 2015-08-10, o godz. 02:42:21
Mike Frysinger <[hidden email]> napisał(a):

> 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.

--
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

attachment0 (968 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: .gitignore

Mike Frysinger
On 10 Aug 2015 09:17, Michał Górny wrote:

> Dnia 2015-08-10, o godz. 02:42:21 Mike Frysinger napisał(a):
> > On 10 Aug 2015 08:28, Justin (jlec) wrote:
> > > 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.
there's no reason people can't use these on their own system.  there's no
reason they should be added to the git repo which means, if a user opted
to utilize them, they should be ignored.
-mike

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: .gitignore

Justin Lecher (jlec)
In reply to this post by Mike Frysinger
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



signature.asc (970 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: .gitignore

Anthony G. Basile
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.)

--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : [hidden email]
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA


Reply | Threaded
Open this post in threaded view
|

Re: .gitignore

Mike Gilbert-2
In reply to this post by Mike Frysinger
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

Reply | Threaded
Open this post in threaded view
|

Re: .gitignore

Rich Freeman
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.

--
Rich

Reply | Threaded
Open this post in threaded view
|

Re: .gitignore

Daniel Campbell (zlg)
-----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.
>
++

- --
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVyO2pAAoJEAEkDpRQOeFwmMwQAMBNw6VA3UEINvi6RgyW6NJJ
a+6QYB2RigTxOJP3nlnTXywahme1Mxtdp8X/rcebHZ0LUi5XSup+n6mGljcUHsx+
Gl09zShXoHxRdDX2JFsptt6YSVr7gXMgT83iFUDGRAKVPFIvJ4Q0jFzWjj0MD0KW
4363Oz2+5/Wdt85vKcLuT8QLG+9niEaxHab2VgauHieFYPALdTdhaEX0DTxTf/6s
M7oz8IN8p+iKbXbks0q0ZhsbJSIcOKLxE6IQ1alftFFeMkbP5wyxH5QLOFKlk6eG
oojNVXlxwvcz+nVnnYVPLhGDpPjdOndjkJ0P+uqsuLA/QIK7rwKy7VGDaFNX9zUD
2fxUNqKXstQXUBkvrzXDNDBpqWuh9v27bbS9Dx+5iJMVIUNm1YegM+JyIor9bBVT
UKeixNwYanYtWNJDGmFluc3vnIwuDqgMXC9dYrDdk3a1wPXj2l/kUmljl1wr5Ora
9BCaVSLAENg+VaNhQ8IkY5LcUnyLw/O3T4SLydqAJwc0u9+uwrcmSndwPAmRnp7U
eg/AccY1/PXARTK+u56yVzmApP6GHUz+tFIQ3frobYO3YOhT0xZojP8ecuMAkeiw
C4KRtVDRgNXmu/5FPvIMzhNNJPB0U1WFS7ZphOtGG2adRkXl4kGzmVi9QEFGGL3+
sDIclOHeOXp1LGP17Ek4
=jJqm
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: .gitignore

Mike Gilbert-2
In reply to this post by Mike Gilbert-2
On Mon, Aug 10, 2015 at 11:04 AM, Mike Gilbert <[hidden email]> wrote:

> 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.

Reply | Threaded
Open this post in threaded view
|

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

hasufell
In reply to this post by Rich Freeman
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

Reply | Threaded
Open this post in threaded view
|

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

Andrew Savchenko
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.

Best regards,
Andrew Savchenko

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Andrew Savchenko
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.

Best regards,
Andrew Savchenko

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

hasufell
In reply to this post by Andrew Savchenko
On 08/10/2015 10:47 PM, 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.
>

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

Reply | Threaded
Open this post in threaded view
|

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

Aaron W. Swenson-2
In reply to this post by Andrew Savchenko
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.

Users can fetch/pull from Github.

https://github.com/gentoo/gentoo

signature.asc (354 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Michał Górny-5
In reply to this post by Andrew Savchenko
Dnia 2015-08-10, o godz. 23:47:21
Andrew Savchenko <[hidden email]> napisał(a):

> 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.

--
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

attachment0 (968 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Michał Górny-5
In reply to this post by Andrew Savchenko
Dnia 2015-08-10, o godz. 23:49:55
Andrew Savchenko <[hidden email]> napisał(a):

> 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.
Do you mean git mirrors of the original repo, or md5-cache propagated
copy for users syncing? The latter is available for a few months now
[1,2].

[1]:https://github.com/gentoo-mirror/
[2]:https://wiki.gentoo.org/wiki/Project:Repository_mirror_and_CI

--
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

attachment0 (968 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rsync mirror security

Matthias Maier-3
In reply to this post by Aaron W. Swenson-2
> 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.

Best,
Matthias


signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rsync mirror security

Mike Frysinger
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

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rsync mirror security

Kent Fredric
In reply to this post by Matthias Maier-3
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.

--
Kent

KENTNL - https://metacpan.org/author/KENTNL

123