Ian Stakenvicius:
>> I wonder if it would make sense to set up a practice git tree
>> somewhere so that people can try working together on workflows/etc.
>> We can clone a migrated tree (I have one from a few days ago on
>> github).
>
> Definitely. I'd volunteer for that (doing my updates to bot
On Sat, Sep 20, 2014 at 10:28 AM, hasufell wrote:
> Ian Stakenvicius:
>>> I wonder if it would make sense to set up a practice git tree
>>> somewhere so that people can try working together on workflows/etc.
>>> We can clone a migrated tree (I have one from a few days ago on
>>> github).
>>
>> Def
Rich Freeman:
>
> Would it make more sense to use a migrated repository as the starting
> point, such as this one:
> https://github.com/rich0/gentoo-gitmig-2014-09-15
>
Not sure why. The old history is irrelevant for testing git workflow.
The repository is also fairly small, even without shallo
On Tue, Sep 16, 2014 at 07:26:06AM -0400, Rich Freeman wrote:
> On Tue, Sep 16, 2014 at 6:18 AM, hasufell wrote:
> > Ulrich Mueller:
> >>
> >> ChangeLogs are aimed at users
> >
> > Did any1 ask them if they care?
> >
>
> I'm sure somebody will reply and say that they care.
Yup, mainly because of
On 2014.09.18 00:31, Jack Morgan wrote:
> Hello,
>
> The PowerPC development team has had our 2nd monthly meeting and I
> wanted to provide an update on where we are.
>
[snip]
> I've sent email to the following devs but haven't head back yet so
> don't
> know your current status.
>
> Mark Loes
Steven J. Long:
>
> VCS commit messages are very different to the ebuild Changelogs ime.
Yes, but this does not even apply to the current gentoo CVS workflow
(compare the cvs commit messages with the ChangeLog entries, e.g. for
sys-apps/portage).
> I would ask that you consider the different pur
On Sat, Sep 20, 2014 at 12:48 PM, hasufell wrote:
> Steven J. Long:
>
>> Either way, I don't think the discussion about Changelogs should *at all*
>> affect the move to git;
>
> Correct, because this wouldn't even be a regression to the current CVS
> workflow.
>
That depends a great deal on how
Rich Freeman:
> On Sat, Sep 20, 2014 at 12:48 PM, hasufell wrote:
>> Steven J. Long:
>>
>>> Either way, I don't think the discussion about Changelogs should *at all*
>>> affect the move to git;
>>
>> Correct, because this wouldn't even be a regression to the current CVS
>> workflow.
>>
>
> That
> On Wed, 17 Sep 2014, Aaron W. Swenson wrote:
> My argument is Git using SHA-1 for checksumming is not the weakest
> part of our security model.
I had always assumed that robbat2's series of GLEPs (57 to 61) would
be implemented at some point. So security from the developer to the
master rep
On Sat, Sep 20, 2014 at 2:09 PM, Ulrich Mueller wrote:
>> On Wed, 17 Sep 2014, Aaron W. Swenson wrote:
>
>> My argument is Git using SHA-1 for checksumming is not the weakest
>> part of our security model.
>
> I had always assumed that robbat2's series of GLEPs (57 to 61) would
> be implemente
Ulrich Mueller:
>
> Have these
> plans been abandoned, and are we now planning to distribute the tree
> to users via Git, where everything goes through the bottleneck of a
> SHA-1 sum, which was never intended as a security feature?
>
This is a bug in git. Do you want us to wait until it is reso
> On Sat, 20 Sep 2014, hasufell wrote:
>> Have these plans been abandoned, and are we now planning to
>> distribute the tree to users via Git, where everything goes through
>> the bottleneck of a SHA-1 sum, which was never intended as a
>> security feature?
> This is a bug in git. Do you wan
Ulrich Mueller:
>> On Sat, 20 Sep 2014, hasufell wrote:
>
>>> Have these plans been abandoned, and are we now planning to
>>> distribute the tree to users via Git, where everything goes through
>>> the bottleneck of a SHA-1 sum, which was never intended as a
>>> security feature?
>
>> This i
On Sat, Sep 20, 2014 at 4:40 PM, Ulrich Mueller wrote:
>> On Sat, 20 Sep 2014, hasufell wrote:
>
>>> Have these plans been abandoned, and are we now planning to
>>> distribute the tree to users via Git, where everything goes through
>>> the bottleneck of a SHA-1 sum, which was never intended
On 21 September 2014 09:01, hasufell wrote:
> Because there are other VCSs it is not a bug??
>
>
No, it just means "using SHA1 for making a repository work" is not a bug,
just like using "i am number 6, parent is number 5" is not a "security" bug.
> Of course it is a bug since it is in the gpg-
Kent Fredric:
>
> He is proposing quite the opposite. He's saying "git is not secure in this
> way, but lets not let that stop us, migrate and fix that after the fact or
> we'll never get around to it, because all this debate is the perfect being
> the enemy of the good".
>
I didn't see him say
> On Sat, 20 Sep 2014, hasufell wrote:
>>> This is a bug in git. Do you want us to wait until it is resolved?
>>
>> Not a bug. There are VCSs (like Subversion or Bazaar) that use simple
>> revision numbers to identify their commits. Git happens to use a hash,
>> which is perfectly fine as lo
On 21 September 2014 09:18, hasufell wrote:
> Kent Fredric:
> >
> > He is proposing quite the opposite. He's saying "git is not secure in
> this
> > way, but lets not let that stop us, migrate and fix that after the fact
> or
> > we'll never get around to it, because all this debate is the perfe
Ulrich Mueller:
>> So you are suggesting to not migrate at all or severely break the
>> workflow because someone might forge _working code_ with a specific
>> SHA1? There is no efficient algorithm for that afaik, those are just
>> about finding _any_ collision and even then it takes considerable
>>
You'v quoted the wrong guy.
On 21 September 2014 09:18, hasufell wrote:
> I didn't see him saying that. It rather sounds like we want to have
> thick signed Manifests and break pull requests and whatnot.
>
Those aren't the only options.
We could of course develop a custom commit signature system, either in the
commit itse
You're following the wrong train down the wrong tracks. Git [0-9a-f]{40} is
to CVS 1[.][1-9][0-9]+. You're arguing that CVS is more secure because its
commits are sequential numbers.
On Sat, Sep 20, 2014 at 4:20 PM, Ulrich Mueller wrote:
> > On Sat, 20 Sep 2014, hasufell wrote:
>
> >>> This
On Sat, Sep 20, 2014 at 8:58 PM, Gordon Pettey wrote:
> You're following the wrong train down the wrong tracks. Git [0-9a-f]{40} is
> to CVS 1[.][1-9][0-9]+. You're arguing that CVS is more secure because its
> commits are sequential numbers.
Ulrich is well-aware of that. His argument is that wi
Rich Freeman wrote:
> I sill think it makes more sense to start with a threat model and go
> from there.
I agree. It's a great project to tackle after the migration.
For migrating I agree with you that it's fine to do whatever.
Really. This year. As in before 2015. There are three more months.
On Sat, Sep 20, 2014 at 9:27 PM, Peter Stuge wrote:
>
> I've so far gotten zero feedback on my hosting offer, intended to
> help find some starting processes.
>
hassufel's repository on github should be more than adequate:
https://github.com/gentoo/gentoo-gitmig
If we need history we can always
Kent Fredric posted on Sun, 21 Sep 2014 09:14:36 +1200 as excerpted:
> That is to say: without gpg, you can just create some random commit with
> some arbitrary content and push it somewhere, and you can pretend you're
> a gentoo dev and pretend you're writing commits as them.
>
> GPG sufficientl
Rich Freeman wrote:
> > I've so far gotten zero feedback on my hosting offer, intended to
> > help find some starting processes.
>
> hassufel's repository on github should be more than adequate:
> https://github.com/gentoo/gentoo-gitmig
The very first email in this thread pointed out that it is d
On Sat, Sep 20, 2014 at 8:20 PM, Rich Freeman wrote:
On Sat, Sep 20, 2014 at 8:58 PM, Gordon Pettey wrote:
> You're following the wrong train down the wrong tracks. Git [0-9a-f]{40}
is
> to CVS 1[.][1-9][0-9]+. You're arguing that CVS is more secure because its
> commits are sequential numbers.
28 matches
Mail list logo
