On Fri, Jan 22, 2016 at 10:00 AM, Santiago Torres wrote:
> On Thu, Jan 14, 2016 at 09:21:28AM -0800, Stefan Beller wrote:
>> On Thu, Jan 14, 2016 at 9:16 AM, Santiago Torres wrote:
>> > Hello Stefan, thanks for your feedback again.
>> >
>> >> This is what push
On Thu, Jan 14, 2016 at 09:21:28AM -0800, Stefan Beller wrote:
> On Thu, Jan 14, 2016 at 9:16 AM, Santiago Torres wrote:
> > Hello Stefan, thanks for your feedback again.
> >
> >> This is what push certs ought to solve already?
> >
> > Yes, they aim to solve the same issue.
> I assume you are assuming here that the "push to upstream" doesn't
> involve some kind of human verification? If someone tried pushing
> something like this to Linus, he would be checking the git diff stats
> and git commit structure for things that might look like "developer
> negligence".
On Sat, Dec 19, 2015 at 12:30:18PM -0500, Santiago Torres wrote:
> > Now, the crazy behavior where github users randomly and promiscuously
> > do pushes and pull without doing any kind of verification may very
> > well be dangerous.
>
> Yes, we were mostly familiar with this workflow before
On Tue, Dec 15, 2015 at 10:26:39PM -0500, Santiago Torres wrote:
> 4) The developer pushes to upstream. All the traffic can be re-routed
> back to the original repository. The target branch now contains a
> vulnerable piece of code.
I assume you are assuming here that the "push to upstream"
On Thu, Dec 17, 2015 at 08:06:36PM -0500, Santiago Torres wrote:
> > This is what push certificates ought to solve.
> > The server records all pushes and its signed certificates of pushes
> > and by the difference of the
> > refs (either in packed refs or as a loose ref) to the push certificate
>
On Tue, Dec 15, 2015 at 10:26:39PM -0500, Santiago Torres wrote:
> An example of a malicious commit merge follows:
>
> 1) The attacker controlling or acting as the upstream server identifies
> two branches: one in which the unsuspecting developer is working on, and
> another in which a
Hi Stefan, thanks for the insight.
> This is what push certificates ought to solve.
> The server records all pushes and its signed certificates of pushes
> and by the difference of the
> refs (either in packed refs or as a loose ref) to the push certificate
> this tampering of
> the server can
Hello everyone,
I'm Santiago, a PhD student at NYU doing research about secure software
development pipelines. We've been studying different aspects of Git
lately, (as it is an integral part of many projects) and we believe
we've found a vulnerabilty in the way Git structures/signs metadata.
An
On Tue, Dec 15, 2015 at 7:26 PM, Santiago Torres wrote:
> Hello everyone,
>
> I'm Santiago, a PhD student at NYU doing research about secure software
> development pipelines. We've been studying different aspects of Git
> lately, (as it is an integral part of many projects) and
10 matches
Mail list logo