Initial TUF integration with RubyGems

[Tony Arcieri]

Hi there! The team here at Square has some code for you to look at if you'd
like to perform some initial review.

We're committing to the "tuf" branch on the Square fork of RubyGems and
RubyGems.org:

https://github.com/square/rubygems/commits/tuf
https://github.com/square/rubygems.org/commits/tuf

So far the server contains the main code spike, including the code
necessary to generate TUF metadata and download and verify a gem.

You can find the client here:

https://github.com/square/rubygems.org/blob/tuf/script/fetch-me-a-gem-with-tuf

We'll be moving this code into the RubyGems client, which is a bit tricky
as we can only depend on the standard library and still need to work on
ancient versions of Ruby that don't even ship a JSON parser.

--
Tony Arcieri
_______________________________________________
RubyGems-Developers mailing list
http://rubyforge.org/projects/rubygems
RubyGems-...@rubyforge.org
http://rubyforge.org/mailman/listinfo/rubygems-developers

[Tony Arcieri]

One thing to note is we're using RSASSA PKCS#1 v1.5 with SHA-512 for
digital signatures:

https://github.com/square/rubygems/blob/tuf/lib/rubygems/tuf/signer.rb#L25

Ruby doesn't support RSASSA-PSS. I don't think this is problematic though:
there aren't known attacks on PKCS#1 v1.5 for digital signatures, and the
scheme is deterministic which is arguably desirable.

[Trishank Karthik Kuppusamy]

Sounds great, thanks for letting us know! :)

We will be sure to review the code. I am personally going to be busy the
next few hours, but I should have some free time to look at this later
tonight.

On 11/20/2013 02:06 PM, Xavier Shay wrote:
> fwiw I'm working on cleaning up the rubygems.org <http://rubygems.org>
> code
> here: https://github.com/square/rubygems.org/commits/tuf-metadata-generation

>
>
> On Wed, Nov 20, 2013 at 11:04 AM, Tony Arcieri <bas...@gmail.com

> <mailto:bas...@gmail.com>> wrote:
>
> Hi there! The team here at Square has some code for you to look at
> if you'd like to perform some initial review.
>
> We're committing to the "tuf" branch on the Square fork of RubyGems
> and RubyGems.org:
>
> https://github.com/square/rubygems/commits/tuf
> https://github.com/square/rubygems.org/commits/tuf
>
> So far the server contains the main code spike, including the code
> necessary to generate TUF metadata and download and verify a gem.
>
> You can find the client here:
>
> https://github.com/square/rubygems.org/blob/tuf/script/fetch-me-a-gem-with-tuf
>
> We'll be moving this code into the RubyGems client, which is a bit
> tricky as we can only depend on the standard library and still need
> to work on ancient versions of Ruby that don't even ship a JSON parser.
>
> --
> Tony Arcieri
>

> --
> You received this message because you are subscribed to the Google
> Groups "RubyGems Update Framework" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to rubygems-tuf...@googlegroups.com
> <mailto:rubygems-tuf%2Bunsu...@googlegroups.com>.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "RubyGems Update Framework" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to rubygems-tuf...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Tony Arcieri]

I'm seeing a few discrepancies in root.txt. I'm looking at the encoding
here:

http://mirror1.poly.edu/test-rubygems/metadata/root.txt

The PEM encoded pubkey doesn't have "\n" literals where newlines would
ordinarily be. Instead it's using spaces?

When I take the SHA256 digest of the DER encoding of the certificate in
root.txt, I get:

6ee8101a3ff89933143ac714f7ab883329e1a65045e577238cf93507a30ccfa8

This doesn't match the one in the document
(a48adfc56133e328957ecbe2511b726573cfc02091dc534357f4a436b3da7cc7).
According to the TUF specification:


The KEYID of a key is the hex representation of the SHA-256 hash of the
canonical encoding of the key.


Does canonical encoding mean something other than DER here?

[Vladimir Diaz]

Canonical refers to Canonical JSON form, as specified at
http://wiki.laptop.org/go/Canonical_JSON . It's a restricted dialect of
JSON in which keys are always lexically sorted, there is no whitespace,
floats aren't allowed, and only quote and backslash get escaped.

We set the key object<https://github.com/theupdateframework/tuf/blob/develop/docs/tuf-spec.txt#L445-L449>(python
dictionary) in Canonical JSON form so that we generate a consistent
keyid. It is not the SHA256 of the DER encoding, nor of the formatted json
in "root.txt". We write json metadata as follows:

# The metadata object is saved to 'file_object'. The keys
# of the objects are sorted and indentation is used.
json.dump(metadata, file_object, indent=1, sort_keys=True)

[Trishank Karthik Kuppusamy]

On 11/20/2013 03:44 PM, Trishank Karthik Kuppusamy wrote:
> Sounds great, thanks for letting us know! :)
>
> We will be sure to review the code. I am personally going to be busy the
> next few hours, but I should have some free time to look at this later
> tonight.
>

I shared a Google Doc with Tony, Xavier, Justin and Vlad which contains
our code review. We will open this up later as things mature.

[Benjamin Fleischer]

Thanks all for this!

FYI, I've (with @drbrain) created a rubygems guide security
page http://guides.rubygems.org/security/#using_gems

Please keep help me et al keep it up to date and correct as Gem::TUF rolls
out.
(e.g. https://github.com/rubygems/guides/pull/70#issuecomment-29015903 )

There's also an open issue in the guide with, I think, a good question: How
to report gem security issues to an author/rubygems.org and how a gem
author should publicize the gem release.
<https://github.com/rubygems/guides/issues/62> (very few seem to [ANN] on
ruby-lang)

Thanks!
-Benjamin

[Tony Arcieri]

On Fri, Nov 22, 2013 at 9:15 AM, Benjamin Fleischer <bflei...@gmail.com>wrote:

> Please keep help me et al keep it up to date and correct as Gem::TUF rolls
> out.
> (e.g. https://github.com/rubygems/guides/pull/70#issuecomment-29015903 )
>

There's still a lot of work to be done on Gem::TUF. What we'll be releasing
(hopefully today in PR form) is more of a proof-of-concept than something
that's ready to use, but we hope it's enough to get the ball rolling.

> There's also an open issue in the guide with, I think, a good question:
> How
> to report gem security issues to an author/rubygems.org and how a gem
> author should publicize the gem release.
> <https://github.com/rubygems/guides/issues/62> (very few seem to [ANN] on
> ruby-lang)

I'd suggest announcing through Rubysec:

http://rubysec.github.io/