Re: Death to git://! Long live git://!

[Christian Seiler]

On 01/08/2016 04:43 PM, Paul Tagliamonte wrote:
> We still have `git://` all over the place, for instance, on Vcs-Git on
> control files. That makes me sad. Boo insecure transports.

Ben Hutchings posted this not too long ago on Planet Debian:
http://womble.decadent.org.uk/blog/securing-debcheckout-of-git-repositories.html

Regards,
Christian



signature.asc
Description: OpenPGP digital signature

Re: Death to git://! Long live git://!

[Christoph Anton Mitterer]

On Fri, 2016-01-08 at 09:35 -0800, Russ Allbery wrote:
> Moving the goalposts from trivial MITM via a rogue AP to obtaining a
> fradulent SSL certificate is probably not "hard" security, whatever
> that
> means to you, but is a substantial increase the level of work
> required for
> the attacker.
Well, I think that's what most people wrongly assume and therefore may
easily fool themselves into a false sense of security.

Sure, such an attack is probably not doable in 5mins for the
neighbouring colleague who wants to play a prank - but so one is
typically not the person who really wants to attack a project like
Debian.

And as I've said, the typical procedure how verification takes place on
most CAs involves so many unsecured paths, mail, whois, how the whois
is set by the (presumed) owner, how the registrar communicates that to
the registry , how the CA retrieves the whois...

It seems foolish, if at the one side many crypto algos (MD5, DSS, etc.)
and keylenghts are considered to be not enough by people, while on the
other side, they put their whole trust into the above weak procedure to
secure their 4096 bit keys ;-)


>   Given that it's a fairly trivial change in most cases,
> since most Git services already expose the repository via HTTPS, I'm
> not
> sure why you're objecting.
I didn't object... I just wanted to express that where possible, ssh
should be used rather than https.
AFAIU, DDs and DMs already have some sort of trust path to Debian (and
I hope it's better than trusting GANDI ;-) ), so they should already
have a secure way to retrieve the public host keys of Debian Servers,
and if not, simply provide them in a package, or somewhere signed by
some Debian Archive key or so.

Of course this applies only to the actual DDs and DMs, and not to
anonymous access - there the best we can get is of course https (as you
pointed out yourself, securing.

Unfortunately, Debian put all its trust-eggs into someone else's basket
- GAND - and thus into the basket of UTN (which belongs to whom right
now?), and thus IIRC under the authority of national security letters
and gag orders.
I've already mentioned previously that this was at best questionable,
because anyone who's more deply into Debian than just visiting the
website (i.e. reading security.debian.org, BTS webinterface, accesing
the mailing list archives - in short, everything that's https secured)
has now no longer the chance to really securely interact with this
systems.

When Debian had its own CA, this was at least in principle possible and
it would have also allowed to really securely use git over https with
Debian's repos.
Again, at least in principle, because IIRC, git didn't directly allow
to set the trusted CA for a repo (or does it? :) ).


> I'm not letting random Internet users ssh into my Git repository
> host,
> thanks.  Securing untrusted ssh is a pain with a lot of fail-open
> pitfalls.  I always tightly firewall ssh to only IP addresses I'm
> actually
> using.
Sorry, I should have made more clear, that I was talking about people
who typically have write-access to these repos, from which one
could/should hope, that they have a proper trust path and are allowed
some form of access anyway.

Oh and I should perhaps mention,... at least when using git with gitolite, I'm 
fairly confident that one actually can secure ssh enough that it shouldn't be a 
problem to give people access even it those are not 100% trusted.
One can restrict things from ssh side quite nicely, and back when I set up my 
own gitservers, I got Sitaram to add a shell mode of gitolite, which I think 
increases security even more.
Even a security paranoid as myself doesn't have too many concerns about it =)


> I'm also entertained that you think that the completely unchecked
> host
> keys that everyone always approves without even looking at are better
> security than X.509 CAs, for all the problems those have.
Well I'm always happy if I can help to entertain people ^^
But seriously,... if someone's so stupid to simply accept the remote
keys without checking... there's nothing one can do (unless perhaps
banning such guy for life if one ever finds out).
The same as such person blindly accepts an unverified key, the same
he/she may simply post his/her trusted DD GPG key on pastebin ;)


Cheers,
Chris.

smime.p7s
Description: S/MIME cryptographic signature

Re: Death to git://! Long live git://!

[Paul Tagliamonte]

> I'd like to suggest we move all Vcs-Git entries to either `https` or
> `ssh`.
>

As mapreri points out - this is for anon clone, so only https - as I
pointed out in a blog post years ago, ssh is a bad idea :)

http://blog.pault.ag/post/27268910152/usage-of-vcs-git-in-the-debian-archive



-- 
:wq

Re: Death to git://! Long live git://!

[Scott Kitterman]

On Friday, January 08, 2016 10:43:40 AM Paul Tagliamonte wrote:
> Hey devel,
> 
> We still have `git://` all over the place, for instance, on Vcs-Git on
> control files. That makes me sad. Boo insecure transports.
> 
> `git://` is plaintext, and plaintext transports are bad.
> 
> I'd like to suggest we move all Vcs-Git entries to either `https` or
> `ssh`.
...

As mentioned on #debian-devel, I filed #810381 against debian-policy to mention 
that the Vcs-$VCS entries ought to be secure.

Scott K

signature.asc
Description: This is a digitally signed message part.

Re: Death to git://! Long live git://!

[Russ Allbery]

Christoph Anton Mitterer  writes:
> On Fri, 2016-01-08 at 10:43 -0500, Paul Tagliamonte wrote:

>> I'd like to suggest we move all Vcs-Git entries to either `https` or

> I doubt https will give any real hard additional security, based on the
> inherent problems of the X.509 CA system.

Moving the goalposts from trivial MITM via a rogue AP to obtaining a
fradulent SSL certificate is probably not "hard" security, whatever that
means to you, but is a substantial increase the level of work required for
the attacker.  Given that it's a fairly trivial change in most cases,
since most Git services already expose the repository via HTTPS, I'm not
sure why you're objecting.

> Thus using ssh AND signed tags or even better signed commits seems to be
> the best solution from a security PoV :)

I'm not letting random Internet users ssh into my Git repository host,
thanks.  Securing untrusted ssh is a pain with a lot of fail-open
pitfalls.  I always tightly firewall ssh to only IP addresses I'm actually
using.

I'm also entertained that you think that the completely unchecked host
keys that everyone always approves without even looking at are better
security than X.509 CAs, for all the problems those have.

-- 
Russ Allbery (r...@debian.org)   

Bug#810378: lintian: suggest to use https:// over git:// (was: Re: Death to git://! Long live git://!)

[Ansgar Burchardt]

Package: lintian
Severity: wishlist

Paul Tagliamonte  writes:
> We still have `git://` all over the place, for instance, on Vcs-Git on
> control files. That makes me sad. Boo insecure transports.
>
> `git://` is plaintext, and plaintext transports are bad.
>
> I'd like to suggest we move all Vcs-Git entries to either `https` or
> `ssh`.

I think moving to https:// over git:// is a good idea.  lintian could
probably suggest this change, just like it did with canonical VCS URLs
before.

Ansgar

Re: Death to git://! Long live git://!

[Dominic Hargreaves]

On Fri, Jan 08, 2016 at 10:43:40AM -0500, Paul Tagliamonte wrote:
> Hey devel,
> 
> We still have `git://` all over the place, for instance, on Vcs-Git on
> control files. That makes me sad. Boo insecure transports.
> 
> `git://` is plaintext, and plaintext transports are bad.
> 
> I'd like to suggest we move all Vcs-Git entries to either `https` or
> `ssh`.
> 
> Signing tags is a good step, yes, but there will always be unsigned
> contents at the head of the branch, and users won't always check them
> when cloning a package locally. I'm sure some DDs out there will even
> debcheckout and upload after checking a `git diff` rather than a
> `debdiff`, because git never lies, right?
> 
> Not everyone pulls down the package and uses debdiff, and it only takes
> one mistake to own systems.

Switching to https does prevents some attacks and generally seems like a
good idea, but does not, of course, eliminate the possibility of rogue
code being committed to the source repository. Maintainers will still
need to judge whether the repository they are pulling from (both the
infrastructure and the push access) is sufficiently trustworthy to not
use without checking against packages (or previous versions of their
trusted local repo).

Cheers,
Dominic.

Re: Death to git://! Long live git://!

[Christoph Anton Mitterer]

On Fri, 2016-01-08 at 10:43 -0500, Paul Tagliamonte wrote:
> I'd like to suggest we move all Vcs-Git entries to either `https` or
I doubt https will give any real hard additional security, based on the
inherent problems of the X.509 CA system.

Per default, git would take the system CA store, which per default
contain some large number (IIRC ~100?) of CAs, some of them which have
already proven to be either incompetent or more likely malicious,
others from totalitarian countries or other countries known to most
likely make use of forged certificates for evil purposes.

And even if a CA could be assumed to not do bad things,... most CAs
offer certs based on some challenge response against whois data via
email.
The email which is completely unsecured as well as the whois..


Thus using ssh AND signed tags or even better signed commits seems to
be the best solution from a security PoV :)


Cheers,
Chris.

smime.p7s
Description: S/MIME cryptographic signature

Re: Death to git://! Long live git://!

[Paul Tagliamonte]

Good point, and I stand corrected. Thanks!

Let's beat GitHub!
  Paul

On Fri, Jan 8, 2016 at 10:47 AM, Andrew Shadura  wrote:

> On 08/01/16 16:43, Paul Tagliamonte wrote:
> > `git://` provides no upside and really shouldn't exist anymore. GitHub
> > has even turned it off[1]
> >
> > Are we going to let GitHub do best practices better than Debian? Hello
> > no! Let's do this.
>
> > [1]:
> https://github.com/blog/809-git-dumb-http-transport-to-be-turned-off-in-90-days
>
> That's not true: git:// still works on GitHub, and the post you linked
> to actually says they're switching off http://, the dumb one.
>
> --
> Cheers,
>   Andrew
>
>


-- 
:wq

Re: Death to git://! Long live git://!

[Alexandre Detiste]

Hi,

> http://blog.pault.ag/post/27268910152/usage-of-vcs-git-in-the-debian-archive
>
> Enter github.com/debian
>
> – IMHO, we should consider putting the repos that are already on
> GitHub under Debian namespace, so that the team of maintainers
> may be able to add new collaborators.

I'd like to move my two native packages there:

 https://github.com/a-detiste/cruft
 https://github.com/a-detiste/cruft-ng

but GitHub only allows to 

  "Transfer this repository to another user or
  to an organization where you have admin rights."

and then later confirms it:

  "You don’t have admin rights to Debian"

So I could give personaly it to someone I trust from this
team who would move it again to github.com/debian;
that's weird.

Greets,

Alexandre



signature.asc
Description: This is a digitally signed message part.

Re: Death to git://! Long live git://!

[Mehdi Dogguy]

On 2016-01-08 16:43, Paul Tagliamonte wrote:

Hey devel,

We still have `git://` all over the place, for instance, on Vcs-Git on
control files. That makes me sad. Boo insecure transports.

`git://` is plaintext, and plaintext transports are bad.

I'd like to suggest we move all Vcs-Git entries to either `https` or
`ssh`.



Possibly also add a --secure flag to debcheckout so that git:// repos
are checked out using https:// if --secure if turned on? There exists
already an --auth flag which replaces git:// by git+ssh:// (also
configurable using the DEBCHECKOUT_AUTH_URLS environment variable).

The lintian flag is a good idea too.

--
Mehdi