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
when attacking the TLS layer of a git connection
would let an attacker into a system partition that makes no other use of
TLS/https other than git-over-https... thus it is only a minor detail.
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness
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
On Fri, 29 May 2015 13:55:31 +0800
Paul Wise p...@debian.org 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
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 the
On Fri, May 29, 2015 at 10:21:09PM +1000, Riley Baird wrote:
On Fri, 29 May 2015 13:55:31 +0800
Paul Wise p...@debian.org 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
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/etc
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 normal CA roots.
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 is
Philipp Kern pk...@debian.org 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
recommend using https:// instead of git://
_for Debian's git services_, the cost noted above would not apply for
any Debian users because in theory we can use the Debian-specific CA.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
]] 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
HTTPS.
In the specific case where we'd recommend using https:// instead of
git:// _for Debian's git services_, the cost noted above would not apply
for any Debian users because in theory we can use the Debian-specific
CA.
If we can use a Debian-specific CA, we can do cert pinning, since we're
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
Russ Allbery, 2015-05-27 22:23:02 -0700 :
Josh Triplett j...@joshtriplett.org 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
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 proprietary
]] 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
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 suppose.
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 abstract
Roland Mas lola...@debian.org 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,
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
you manually check the commit number) in
preference to https:// (at least some security)?
https://wiki.debian.org/Alioth/Git#Accessing_repositories
https:// is actually just as efficient as git:// these days (other than the
minor overhead of TLS, which is worth it for security).
Why
:// (at least some security)?
https://wiki.debian.org/Alioth/Git#Accessing_repositories
https:// is actually just as efficient as git:// these days (other than the
minor overhead of TLS, which is worth it for security).
Why? Which attack do you envision (other than the ridiculous the NSA would see
you manually check the commit number) in
preference to https:// (at least some security)?
https://wiki.debian.org/Alioth/Git#Accessing_repositories
https:// is actually just as efficient as git:// these days (other than the
minor overhead of TLS, which is worth it for security).
Why
Josh Triplett j...@joshtriplett.org 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
-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_repositories
https:// is actually just as efficient as git:// these days (other than
manually check the commit number) in
preference to https:// (at least some security)?
https://wiki.debian.org/Alioth/Git#Accessing_repositories
https:// is actually just as efficient as git:// these days (other than the
minor overhead of TLS, which is worth it for security).
Why? Which
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_repositories
https
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
some security)?
https://wiki.debian.org/Alioth/Git#Accessing_repositories
When you are in a position to actually mandate the full certificate
validation (i.e. enforce pin and validation on the client, and control
the server certificate), you would get one security benefit out of
HTTPS/TLS for git
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
https://alioth.debian.org/scm/?group_id=100114 SCM tab say how to clone
repo.
First time after waiting 10 sec I drop operation:
desktop+bash# git clone
https://alioth.debian.org/anonscm/git/bash-completion/bash-completion.git
Cloning into 'bash-completion'...
^C
https://alioth.debian.org
32 matches
Mail list logo
