While we're on the subject of git security...should we stop recommending
that non-account-holders use git:// (most efficient, but insecure
against MITM unless you manually check the commit number) in preference
to https:// (at least some security)?
https://wiki.debian.org/Alioth/Git#Accessing_r
On Mon, May 25, 2015, at 09:09, Rebecca N. Palmer wrote:
> While we're on the subject of git security...should we stop recommending
> that non-account-holders use git:// (most efficient, but insecure
> against MITM unless you manually check the commit number) in preference
> to https:// (at leas
> While we're on the subject of git security...should we stop
> recommending that non-account-holders use git:// (most efficient, but
> insecure against MITM unless you manually check the commit number) in
> preference to https:// (at least some security)?
> https://wiki.debian.org/Alioth/Git#Acces
On Mon, May 25, 2015 at 11:38:06AM -0700, Josh Triplett wrote:
> > While we're on the subject of git security...should we stop
> > recommending that non-account-holders use git:// (most efficient, but
> > insecure against MITM unless you manually check the commit number) in
> > preference to https:
On Wed, May 27, 2015 at 10:08:35AM +0200, Wouter Verhelst wrote:
> On Mon, May 25, 2015 at 11:38:06AM -0700, Josh Triplett wrote:
> > > While we're on the subject of git security...should we stop
> > > recommending that non-account-holders use git:// (most efficient, but
> > > insecure against MIT
Why? Which attack do you envision[...]that would
be thwarted by https but not by signed commits?
I don't; I see https as easier and hence more likely to actually get
used in practice.
Telling users to use the existing https:// instead of git:// is a simple
change to the wiki; enabling https on
On Wed, May 27, 2015 at 10:08:35AM +0200, Wouter Verhelst wrote:
> On Mon, May 25, 2015 at 11:38:06AM -0700, Josh Triplett wrote:
> > > While we're on the subject of git security...should we stop
> > > recommending that non-account-holders use git:// (most efficient, but
> > > insecure against MITM
On Wed, May 27, 2015 at 10:44:17PM +0100, Dimitri John Ledkov wrote:
> On 27 May 2015 at 09:08, Wouter Verhelst wrote:
> > On Mon, May 25, 2015 at 11:38:06AM -0700, Josh Triplett wrote:
> >> > While we're on the subject of git security...should we stop
> >> > recommending that non-account-holders
On 27 May 2015 at 09:08, Wouter Verhelst wrote:
> On Mon, May 25, 2015 at 11:38:06AM -0700, Josh Triplett wrote:
>> > While we're on the subject of git security...should we stop
>> > recommending that non-account-holders use git:// (most efficient, but
>> > insecure against MITM unless you manuall
On 27 May 2015 at 23:00, wrote:
> On Wed, May 27, 2015 at 10:44:17PM +0100, Dimitri John Ledkov wrote:
>> On 27 May 2015 at 09:08, Wouter Verhelst wrote:
>> > On Mon, May 25, 2015 at 11:38:06AM -0700, Josh Triplett wrote:
>> >> > While we're on the subject of git security...should we stop
>> >>
Josh Triplett writes:
> https:// avoids MITM;
If you aren't doing certificate pinning, I don't think you can really say
this with a straight face.
It makes MITM moderately harder, at the cost of giving money to a bunch of
exploitative clowns who have no concept of what security means.
--
Russ
On Wed, May 27, 2015 at 12:20:03PM +0100, Rebecca N. Palmer wrote:
> >Why? Which attack do you envision[...]that would
> >be thwarted by https but not by signed commits?
> I don't; I see https as easier and hence more likely to actually get used in
> practice.
Well, on that we disagree then, I sup
Russ Allbery, 2015-05-27 22:23:02 -0700 :
> Josh Triplett writes:
>
>> https:// avoids MITM;
>
> If you aren't doing certificate pinning, I don't think you can really say
> this with a straight face.
>
> It makes MITM moderately harder, at the cost of giving money to a bunch of
> exploitative clo
]] Wouter Verhelst
> - Most importantly, you need to configure your webserver and SSL library
> so it disables outdated protocol versions, enables newer secure
> protocol versions (doing so in a way that older proprietary clients
> who don't speak those newer versions yet and make up the ma
On Thu, May 28, 2015 at 10:30:58AM +0200, Tollef Fog Heen wrote:
> ]] Wouter Verhelst
>
> > - Most importantly, you need to configure your webserver and SSL library
> > so it disables outdated protocol versions, enables newer secure
> > protocol versions (doing so in a way that older propriet
Roland Mas writes:
> I understand that behemoths such as Iceweasel may take some time to
> move, but maybe Git could be made to use the TLSA records in DNSSEC?
> Postfix does make use of them, and SSH uses their SSHFP cousins, so it's
> not completely an abstract idea.
> Roland,
> who spent so
On 2015-05-28 09:33:35 +0200 (+0200), Roland Mas wrote:
> I understand that behemoths such as Iceweasel may take some time
> to move, but maybe Git could be made to use the TLSA records in
> DNSSEC? Postfix does make use of them, and SSH uses their SSHFP
> cousins, so it's not completely an abstrac
]] Russ Allbery
> Also, for people coming from Debian hosts talking to the Debian
> infrastructure, at least in theory we *could* do certificate pinning,
> which transforms HTTPS into a worthwhile security protocol. It's not
> exactly trivial to work out the UI and integration problems, and it
>
Excerpts from Russ Allbery's message of 2015-05-27 22:23:02 -0700:
> Josh Triplett writes:
>
> > https:// avoids MITM;
>
> If you aren't doing certificate pinning, I don't think you can really say
> this with a straight face.
>
The word is "avoids", it is not "eliminates". What ever happened t
Clint Byrum writes:
> Excerpts from Russ Allbery's message of 2015-05-27 22:23:02 -0700:
>> If you aren't doing certificate pinning, I don't think you can really say
>> this with a straight face.
> The word is "avoids", it is not "eliminates". What ever happened to
> defense in depth? There's no
On Fri, May 29, 2015 at 7:40 AM, Russ Allbery wrote:
> I'm fine with locking the doors. I'm not fine with paying protection
> money to a Mafia goon who claims they'll lock your windows, and sort of
> sometimes does. It's the extortion component that pisses me off about
> HTTPS.
LetsEncrypt will
On Fri, 29 May 2015 13:55:31 +0800
Paul Wise wrote:
> On Fri, May 29, 2015 at 7:40 AM, Russ Allbery wrote:
>
> > I'm fine with locking the doors. I'm not fine with paying protection
> > money to a Mafia goon who claims they'll lock your windows, and sort of
> > sometimes does. It's the extortio
On Fri, 2015-05-29 at 22:21 +1000, Riley Baird wrote:
> > LetsEncrypt will save us!
>
> I just looked that up. What a wonderful idea!
I don't know how you missed it. My tongue has been hanging out for a
year now. Finally, sanity prevails.
A https cert is supposed to certify www.someone.com is
On Fri, May 29, 2015 at 10:21:09PM +1000, Riley Baird wrote:
> On Fri, 29 May 2015 13:55:31 +0800
> Paul Wise wrote:
> > > If we can use a Debian-specific CA, we can do cert pinning, since we're
> > > then assuming we have some control over the client. I was assuming a
> > > general client where
On Thu, May 28, 2015 at 04:40:52PM -0700, Russ Allbery wrote:
> I'm fine with locking the doors. I'm not fine with paying protection
> money to a Mafia goon who claims they'll lock your windows, and sort of
> sometimes does. It's the extortion component that pisses me off about
> HTTPS.
Perfect
Philipp Kern writes:
> Perfect is the enemy of good. Debian is already paying the protection
> money at this point and TBH I don't understand the resistance to add
> and promote the https:// variant of it. We can still switch to Let's
> Encrypt once it is available.
I don't object to promoting h
> > > > If we can use a Debian-specific CA, we can do cert pinning, since we're
> > > > then assuming we have some control over the client. I was assuming a
> > > > general client where we'd have to play nice with the normal CA roots.
>
> > > Then we would constantly get complaints from Ubuntu/et
On Sat, May 30, 2015 at 11:52:02AM +1000, Riley Baird wrote:
> > > > > If we can use a Debian-specific CA, we can do cert pinning, since
> > > > > we're
> > > > > then assuming we have some control over the client. I was assuming a
> > > > > general client where we'd have to play nice with the no
> > > > > > If we can use a Debian-specific CA, we can do cert pinning, since
> > > > > > we're
> > > > > > then assuming we have some control over the client. I was assuming
> > > > > > a
> > > > > > general client where we'd have to play nice with the normal CA
> > > > > > roots.
>
> > > > >
On Fri, 29 May 2015, Russ Allbery wrote:
> Philipp Kern writes:
> > Perfect is the enemy of good. Debian is already paying the protection
> > money at this point and TBH I don't understand the resistance to add
> > and promote the https:// variant of it. We can still switch to Let's
> > Encrypt on
On Fri, May 29, 2015 at 8:21 PM, Riley Baird wrote:
> If having to manually add a CA annoys the Ubuntu developers that
> much, then surely they could just include the Debian CA certificate to
> Ubuntu's default?
Steve answered the Ubuntu part, but there is also the "etc" people;
there are myriad
31 matches
Mail list logo
