Raised on attempt to Ractor#take if there was an uncaught exception in the Ractor. Its cause will contain the original exception, and ractor is the original ractor it was raised in.
r = Ractor.new { raise "Something weird happened" } begin r.take rescue => e p e # => #<Ractor::RemoteError: thrown by remote Ractor.> p e.ractor == r # => true p e.cause # => #<RuntimeError: Something weird happened> end
Raised on an attempt to access an object which was moved in Ractor#send or Ractor.yield.
r = Ractor.new { sleep } ary = [1, 2, 3] r.send(ary, move: true) ary.inspect # Ractor::MovedError (can not send any methods to a moved object)
This is not an existing class, but documentation of the interface that Scheduler object should comply to in order to be used as argument to Fiber.scheduler and handle non-blocking fibers. See also the “Non-blocking fibers” section in Fiber class docs for explanations of some concepts.
Scheduler’s behavior and usage are expected to be as follows:
When the execution in the non-blocking Fiber reaches some blocking operation (like sleep, wait for a process, or a non-ready I/O), it calls some of the scheduler’s hook methods, listed below.
Scheduler somehow registers what the current fiber is waiting on, and yields control to other fibers with Fiber.yield (so the fiber would be suspended while expecting its wait to end, and other fibers in the same thread can perform)
At the end of the current thread execution, the scheduler’s method scheduler_close is called
The scheduler runs into a wait loop, checking all the blocked fibers (which it has registered on hook calls) and resuming them when the awaited resource is ready (e.g. I/O ready or sleep time elapsed).
This way concurrent execution will be achieved transparently for every individual Fiber’s code.
Scheduler implementations are provided by gems, like Async.
Hook methods are:
io_wait, io_read, io_write, io_pread, io_pwrite, and io_select, io_close
(the list is expanded as Ruby developers make more methods having non-blocking calls)
When not specified otherwise, the hook implementations are mandatory: if they are not implemented, the methods trying to call hook will fail. To provide backward compatibility, in the future hooks will be optional (if they are not implemented, due to the scheduler being created for the older Ruby version, the code which needs this hook will not fail, and will just behave in a blocking fashion).
It is also strongly recommended that the scheduler implements the fiber method, which is delegated to by Fiber.schedule.
Sample toy implementation of the scheduler can be found in Ruby’s code, in test/fiber/scheduler.rb
Module File::Constants defines file-related constants.
There are two families of constants here:
Those having to do with file access.
Those having to do with filename globbing.
File constants defined for the local process may be retrieved with method File::Constants.constants:
File::Constants.constants.take(5) # => [:RDONLY, :WRONLY, :RDWR, :APPEND, :CREAT]
File-access constants may be used with optional argument mode in calls to the following methods:
Read-write access for a stream may be specified by a file-access constant.
The constant may be specified as part of a bitwise OR of other such constants.
Any combination of the constants in this section may be specified.
Flag File::RDONLY specifies the stream should be opened for reading only:
filepath = '/tmp/t.tmp' f = File.new(filepath, File::RDONLY) f.write('Foo') # Raises IOError (not opened for writing).
Flag File::WRONLY specifies that the stream should be opened for writing only:
f = File.new(filepath, File::WRONLY) f.read # Raises IOError (not opened for reading).
Flag File::RDWR specifies that the stream should be opened for both reading and writing:
f = File.new(filepath, File::RDWR) f.write('Foo') # => 3 f.rewind # => 0 f.read # => "Foo"
Flag File::APPEND specifies that the stream should be opened in append mode.
Before each write operation, the position is set to end-of-stream. The modification of the position and the following write operation are performed as a single atomic step.
Flag File::TRUNC specifies that the stream should be truncated at its beginning. If the file exists and is successfully opened for writing, it is to be truncated to position zero; its ctime and mtime are updated.
There is no effect on a FIFO special file or a terminal device. The effect on other file types is implementation-defined. The result of using File::TRUNC with File::RDONLY is undefined.
Flag File::CREAT specifies that the stream should be created if it does not already exist.
If the file exists:
- Raise an exception if File::EXCL is also specified. - Otherwise, do nothing.
If the file does not exist, then it is created. Upon successful completion, the atime, ctime, and mtime of the file are updated, and the ctime and mtime of the parent directory are updated.
Flag File::EXCL specifies that the stream should not already exist; If flags File::CREAT and File::EXCL are both specified and the stream already exists, an exception is raised.
The check for the existence and creation of the file is performed as an atomic operation.
If both File::EXCL and File::CREAT are specified and the path names a symbolic link, an exception is raised regardless of the contents of the symbolic link.
If File::EXCL is specified and File::CREAT is not specified, the result is undefined.
Some file-access constants are defined only on POSIX-compliant systems; those are:
File::SYNC.
File::DSYNC.
File::RSYNC.
File::DIRECT.
File::NOATIME.
File::NOCTTY.
File::NOFOLLOW.
File::TMPFILE.
Flag File::SYNC, File::RSYNC, or File::DSYNC specifies synchronization of I/O operations with the underlying file system.
These flags are valid only for POSIX-compliant systems.
File::SYNC specifies that all write operations (both data and metadata) are immediately to be flushed to the underlying storage device. This means that the data is written to the storage device, and the file’s metadata (e.g., file size, timestamps, permissions) are also synchronized. This guarantees that data is safely stored on the storage medium before returning control to the calling program. This flag can have a significant impact on performance since it requires synchronous writes, which can be slower compared to asynchronous writes.
File::RSYNC specifies that any read operations on the file will not return until all outstanding write operations (those that have been issued but not completed) are also synchronized. This is useful when you want to read the most up-to-date data, which may still be in the process of being written.
File::DSYNC specifies that all data write operations are immediately to be flushed to the underlying storage device; this differs from File::SYNC, which requires that metadata also be synchronized.
Note that the behavior of these flags may vary slightly depending on the operating system and filesystem being used. Additionally, using these flags can have an impact on performance due to the synchronous nature of the I/O operations, so they should be used judiciously, especially in performance-critical applications.
Flag File::NOCTTY specifies that if the stream is a terminal device, that device does not become the controlling terminal for the process.
Defined only for POSIX-compliant systems.
Flag File::DIRECT requests that cache effects of the I/O to and from the stream be minimized.
Defined only for POSIX-compliant systems.
Flag File::NOATIME specifies that act of opening the stream should not modify its access time (atime).
Defined only for POSIX-compliant systems.
Flag File::NOFOLLOW specifies that if path is a symbolic link, it should not be followed.
Defined only for POSIX-compliant systems.
Flag File::TMPFILE specifies that the opened stream should be a new temporary file.
Defined only for POSIX-compliant systems.
When possible, the file is opened in nonblocking mode. Neither the open operation nor any subsequent I/O operations on the file will cause the calling process to wait.
Flag File::BINARY specifies that the stream is to be accessed in binary mode.
Flag File::SHARE_DELETE enables other processes to open the stream with delete access.
Windows only.
If the stream is opened for (local) delete access without File::SHARE_DELETE, and another process attempts to open it with delete access, the attempt fails and the stream is not opened for that process.
Four file constants relate to stream locking; see File#flock:
Flag File::LOCK_EX specifies an exclusive lock; only one process a a time may lock the stream.
Flag File::LOCK_NB specifies non-blocking locking for the stream; may be combined with File::LOCK_EX or File::LOCK_SH.
Flag File::LOCK_SH specifies that multiple processes may lock the stream at the same time.
Flag File::LOCK_UN specifies that the stream is not to be locked.
Filename-globbing constants may be used with optional argument flags in calls to the following methods:
The constants are:
Flag File::FNM_CASEFOLD makes patterns case insensitive for File.fnmatch (but not Dir.glob).
Flag File::FNM_DOTMATCH makes the '*' pattern match a filename starting with '.'.
Flag File::FNM_EXTGLOB enables pattern '{a,b}', which matches pattern ‘a’ and pattern ‘b’; behaves like a regexp union (e.g., '(?:a|b)'):
pattern = '{LEGAL,BSDL}' Dir.glob(pattern) # => ["LEGAL", "BSDL"] Pathname.glob(pattern) # => [#<Pathname:LEGAL>, #<Pathname:BSDL>] pathname.glob(pattern) # => [#<Pathname:LEGAL>, #<Pathname:BSDL>]
Flag File::FNM_NOESCAPE disables '\' escaping.
Flag File::FNM_PATHNAME specifies that patterns '*' and '?' do not match the directory separator (the value of constant File::SEPARATOR).
Flag File::FNM_SHORTNAME allows patterns to match short names if they exist.
Windows only.
Flag File::FNM_SYSCASE specifies that case sensitivity is the same as in the underlying operating system; effective for File.fnmatch, but not Dir.glob.
Flag File::NULL contains the string value of the null device:
On a Unix-like OS, '/dev/null'.
On Windows, 'NUL'.
OpenSSL IO buffering mix-in module.
This module allows an OpenSSL::SSL::SSLSocket to behave like an IO.
You typically won’t use this module directly, you can see it implemented in OpenSSL::SSL::SSLSocket.
Provides classes and methods to request, create and validate RFC3161-compliant timestamps. Request may be used to either create requests from scratch or to parse existing requests that again can be used to request timestamps from a timestamp server, e.g. via the net/http. The resulting timestamp response may be parsed using Response.
Please note that Response is read-only and immutable. To create a Response, an instance of Factory as well as a valid Request are needed.
#Assumes ts.p12 is a PKCS#12-compatible file with a private key #and a certificate that has an extended key usage of 'timeStamping' p12 = OpenSSL::PKCS12.new(File.binread('ts.p12'), 'pwd') md = OpenSSL::Digest.new('SHA1') hash = md.digest(data) #some binary data to be timestamped req = OpenSSL::Timestamp::Request.new req.algorithm = 'SHA1' req.message_imprint = hash req.policy_id = "1.2.3.4.5" req.nonce = 42 fac = OpenSSL::Timestamp::Factory.new fac.gen_time = Time.now fac.serial_number = 1 timestamp = fac.create_timestamp(p12.key, p12.certificate, req)
#Assume we have a timestamp token in a file called ts.der
ts = OpenSSL::Timestamp::Response.new(File.binread('ts.der'))
#Assume we have the Request for this token in a file called req.der
req = OpenSSL::Timestamp::Request.new(File.binread('req.der'))
# Assume the associated root CA certificate is contained in a
# DER-encoded file named root.cer
root = OpenSSL::X509::Certificate.new(File.binread('root.cer'))
# get the necessary intermediate certificates, available in
# DER-encoded form in inter1.cer and inter2.cer
inter1 = OpenSSL::X509::Certificate.new(File.binread('inter1.cer'))
inter2 = OpenSSL::X509::Certificate.new(File.binread('inter2.cer'))
ts.verify(req, root, inter1, inter2) -> ts or raises an exception if validation fails
The HTTPHeader module provides access to HTTP headers.
The module is included in:
Net::HTTPGenericRequest (and therefore Net::HTTPRequest).
The headers are a hash-like collection of key/value pairs called fields.
Headers may be included in:
A Net::HTTPRequest object: the object’s headers will be sent with the request. Any fields may be defined in the request; see Setters.
A Net::HTTPResponse object: the objects headers are usually those returned from the host. Fields may be retrieved from the object; see Getters and Iterators.
Exactly which fields should be sent or expected depends on the host; see:
A header field is a key/value pair.
A field key may be:
A string: Key 'Accept' is treated as if it were 'Accept'.downcase; i.e., 'accept'.
A symbol: Key :Accept is treated as if it were :Accept.to_s.downcase; i.e., 'accept'.
Examples:
req = Net::HTTP::Get.new(uri) req[:accept] # => "*/*" req['Accept'] # => "*/*" req['ACCEPT'] # => "*/*" req['accept'] = 'text/html' req[:accept] = 'text/html' req['ACCEPT'] = 'text/html'
A field value may be returned as an array of strings or as a string:
These methods return field values as arrays:
get_fields: Returns the array value for the given key, or nil if it does not exist.
to_hash: Returns a hash of all header fields: each key is a field name; its value is the array value for the field.
These methods return field values as string; the string value for a field is equivalent to self[key.downcase.to_s].join(', ')):
The field value may be set:
[]=: Sets the value for the given key; the given value may be a string, a symbol, an array, or a hash.
add_field: Adds a given value to a value for the given key (not overwriting the existing value).
delete: Deletes the field for the given key.
Example field values:
String:
req['Accept'] = 'text/html' # => "text/html" req['Accept'] # => "text/html" req.get_fields('Accept') # => ["text/html"]
Symbol:
req['Accept'] = :text # => :text req['Accept'] # => "text" req.get_fields('Accept') # => ["text"]
Simple array:
req[:foo] = %w[bar baz bat] req[:foo] # => "bar, baz, bat" req.get_fields(:foo) # => ["bar", "baz", "bat"]
Simple hash:
req[:foo] = {bar: 0, baz: 1, bat: 2} req[:foo] # => "bar, 0, baz, 1, bat, 2" req.get_fields(:foo) # => ["bar", "0", "baz", "1", "bat", "2"]
Nested:
req[:foo] = [%w[bar baz], {bat: 0, bam: 1}] req[:foo] # => "bar, baz, bat, 0, bam, 1" req.get_fields(:foo) # => ["bar", "baz", "bat", "0", "bam", "1"] req[:foo] = {bar: %w[baz bat], bam: {bah: 0, bad: 1}} req[:foo] # => "bar, baz, bat, bam, bah, 0, bad, 1" req.get_fields(:foo) # => ["bar", "baz", "bat", "bam", "bah", "0", "bad", "1"]
Various convenience methods retrieve values, set values, query values, set form values, or iterate over fields.
Method []= can set any field, but does little to validate the new value; some of the other setter methods provide some validation:
[]=: Sets the string or array value for the given key.
add_field: Creates or adds to the array value for the given key.
basic_auth: Sets the string authorization header for 'Authorization'.
content_length=: Sets the integer length for field 'Content-Length.
content_type=: Sets the string value for field 'Content-Type'.
proxy_basic_auth: Sets the string authorization header for 'Proxy-Authorization'.
set_range: Sets the value for field 'Range'.
set_form: Sets an HTML form data set.
set_form_data: Sets header fields and a body from HTML form data.
Method [] can retrieve the value of any field that exists, but always as a string; some of the other getter methods return something different from the simple string value:
[]: Returns the string field value for the given key.
content_length: Returns the integer value of field 'Content-Length'.
content_range: Returns the Range value of field 'Content-Range'.
content_type: Returns the string value of field 'Content-Type'.
fetch: Returns the string field value for the given key.
get_fields: Returns the array field value for the given key.
main_type: Returns first part of the string value of field 'Content-Type'.
sub_type: Returns second part of the string value of field 'Content-Type'.
range: Returns an array of Range objects of field 'Range', or nil.
range_length: Returns the integer length of the range given in field 'Content-Range'.
type_params: Returns the string parameters for 'Content-Type'.
chunked?: Returns whether field 'Transfer-Encoding' is set to 'chunked'.
connection_close?: Returns whether field 'Connection' is set to 'close'.
connection_keep_alive?: Returns whether field 'Connection' is set to 'keep-alive'.
key?: Returns whether a given key exists.
each_capitalized: Passes each field capitalized-name/value pair to the block.
each_capitalized_name: Passes each capitalized field name to the block.
each_header: Passes each field name/value pair to the block.
each_name: Passes each field name to the block.
each_value: Passes each string field value to the block.
Mixin for HTTP and FTP URIs.
A parser for the pack template language.
Formats generated random numbers in many manners. When 'random/formatter' is required, several methods are added to empty core module Random::Formatter, making them available as Random’s instance and module methods.
Standard library SecureRandom is also extended with the module, and the methods described below are available as a module methods in it.
Generate random hexadecimal strings:
require 'random/formatter' prng = Random.new prng.hex(10) #=> "52750b30ffbc7de3b362" prng.hex(10) #=> "92b15d6c8dc4beb5f559" prng.hex(13) #=> "39b290146bea6ce975c37cfc23" # or just Random.hex #=> "1aed0c631e41be7f77365415541052ee"
Generate random base64 strings:
prng.base64(10) #=> "EcmTPZwWRAozdA==" prng.base64(10) #=> "KO1nIU+p9DKxGg==" prng.base64(12) #=> "7kJSM/MzBJI+75j8" Random.base64(4) #=> "bsQ3fQ=="
Generate random binary strings:
prng.random_bytes(10) #=> "\016\t{\370g\310pbr\301" prng.random_bytes(10) #=> "\323U\030TO\234\357\020\a\337" Random.random_bytes(6) #=> "\xA1\xE6Lr\xC43"
Generate alphanumeric strings:
prng.alphanumeric(10) #=> "S8baxMJnPl" prng.alphanumeric(10) #=> "aOxAg8BAJe" Random.alphanumeric #=> "TmP9OsJHJLtaZYhP"
Generate UUIDs:
prng.uuid #=> "2d931510-d99f-494a-8c67-87feb05e1594" prng.uuid #=> "bad85eb9-0713-4da7-8d36-07a8e4b00eab" Random.uuid #=> "f14e0271-de96-45cc-8911-8910292a42cd"
All methods are available in the standard library SecureRandom, too:
SecureRandom.hex #=> "05b45376a30c67238eb93b16499e50cf"
Generate a random number in the given range as Random does
prng.random_number #=> 0.5816771641321361 prng.random_number(1000) #=> 485 prng.random_number(1..6) #=> 3 prng.rand #=> 0.5816771641321361 prng.rand(1000) #=> 485 prng.rand(1..6) #=> 3
The Gem::Security implements cryptographic signatures for gems. The section below is a step-by-step guide to using signed gems and generating your own.
In order to start signing your gems, you’ll need to build a private key and a self-signed certificate. Here’s how:
# build a private key and certificate for yourself: $ gem cert --build you@example.com
This could take anywhere from a few seconds to a minute or two, depending on the speed of your computer (public key algorithms aren’t exactly the speediest crypto algorithms in the world). When it’s finished, you’ll see the files “gem-private_key.pem” and “gem-public_cert.pem” in the current directory.
First things first: Move both files to ~/.gem if you don’t already have a key and certificate in that directory. Ensure the file permissions make the key unreadable by others (by default the file is saved securely).
Keep your private key hidden; if it’s compromised, someone can sign packages as you (note: PKI has ways of mitigating the risk of stolen keys; more on that later).
In RubyGems 2 and newer there is no extra work to sign a gem. RubyGems will automatically find your key and certificate in your home directory and use them to sign newly packaged gems.
If your certificate is not self-signed (signed by a third party) RubyGems will attempt to load the certificate chain from the trusted certificates. Use gem cert --add signing_cert.pem to add your signers as trusted certificates. See below for further information on certificate chains.
If you build your gem it will automatically be signed. If you peek inside your gem file, you’ll see a couple of new files have been added:
$ tar tf your-gem-1.0.gem metadata.gz metadata.gz.sig # metadata signature data.tar.gz data.tar.gz.sig # data signature checksums.yaml.gz checksums.yaml.gz.sig # checksums signature
If you wish to store your key in a separate secure location you’ll need to set your gems up for signing by hand. To do this, set the signing_key and cert_chain in the gemspec before packaging your gem:
s.signing_key = '/secure/path/to/gem-private_key.pem' s.cert_chain = %w[/secure/path/to/gem-public_cert.pem]
When you package your gem with these options set RubyGems will automatically load your key and certificate from the secure paths.
Now let’s verify the signature. Go ahead and install the gem, but add the following options: -P HighSecurity, like this:
# install the gem with using the security policy "HighSecurity" $ sudo gem install your.gem -P HighSecurity
The -P option sets your security policy – we’ll talk about that in just a minute. Eh, what’s this?
$ gem install -P HighSecurity your-gem-1.0.gem
ERROR: While executing gem ... (Gem::Security::Exception)
root cert /CN=you/DC=example is not trusted
The culprit here is the security policy. RubyGems has several different security policies. Let’s take a short break and go over the security policies. Here’s a list of the available security policies, and a brief description of each one:
NoSecurity - Well, no security at all. Signed packages are treated like unsigned packages.
LowSecurity - Pretty much no security. If a package is signed then RubyGems will make sure the signature matches the signing certificate, and that the signing certificate hasn’t expired, but that’s it. A malicious user could easily circumvent this kind of security.
MediumSecurity - Better than LowSecurity and NoSecurity, but still fallible. Package contents are verified against the signing certificate, and the signing certificate is checked for validity, and checked against the rest of the certificate chain (if you don’t know what a certificate chain is, stay tuned, we’ll get to that). The biggest improvement over LowSecurity is that MediumSecurity won’t install packages that are signed by untrusted sources. Unfortunately, MediumSecurity still isn’t totally secure – a malicious user can still unpack the gem, strip the signatures, and distribute the gem unsigned.
HighSecurity - Here’s the bugger that got us into this mess. The HighSecurity policy is identical to the MediumSecurity policy, except that it does not allow unsigned gems. A malicious user doesn’t have a whole lot of options here; they can’t modify the package contents without invalidating the signature, and they can’t modify or remove signature or the signing certificate chain, or RubyGems will simply refuse to install the package. Oh well, maybe they’ll have better luck causing problems for CPAN users instead :).
The reason RubyGems refused to install your shiny new signed gem was because it was from an untrusted source. Well, your code is infallible (naturally), so you need to add yourself as a trusted source:
# add trusted certificate gem cert --add ~/.gem/gem-public_cert.pem
You’ve now added your public certificate as a trusted source. Now you can install packages signed by your private key without any hassle. Let’s try the install command above again:
# install the gem with using the HighSecurity policy (and this time # without any shenanigans) $ gem install -P HighSecurity your-gem-1.0.gem Successfully installed your-gem-1.0 1 gem installed
This time RubyGems will accept your signed package and begin installing.
While you’re waiting for RubyGems to work it’s magic, have a look at some of the other security commands by running gem help cert:
Options:
-a, --add CERT Add a trusted certificate.
-l, --list [FILTER] List trusted certificates where the
subject contains FILTER
-r, --remove FILTER Remove trusted certificates where the
subject contains FILTER
-b, --build EMAIL_ADDR Build private key and self-signed
certificate for EMAIL_ADDR
-C, --certificate CERT Signing certificate for --sign
-K, --private-key KEY Key for --sign or --build
-A, --key-algorithm ALGORITHM Select key algorithm for --build from RSA, DSA, or EC. Defaults to RSA.
-s, --sign CERT Signs CERT with the key from -K
and the certificate from -C
-d, --days NUMBER_OF_DAYS Days before the certificate expires
-R, --re-sign Re-signs the certificate from -C with the key from -K
We’ve already covered the --build option, and the --add, --list, and --remove commands seem fairly straightforward; they allow you to add, list, and remove the certificates in your trusted certificate list. But what’s with this --sign option?
To answer that question, let’s take a look at “certificate chains”, a concept I mentioned earlier. There are a couple of problems with self-signed certificates: first of all, self-signed certificates don’t offer a whole lot of security. Sure, the certificate says Yukihiro Matsumoto, but how do I know it was actually generated and signed by matz himself unless he gave me the certificate in person?
The second problem is scalability. Sure, if there are 50 gem authors, then I have 50 trusted certificates, no problem. What if there are 500 gem authors? 1000? Having to constantly add new trusted certificates is a pain, and it actually makes the trust system less secure by encouraging RubyGems users to blindly trust new certificates.
Here’s where certificate chains come in. A certificate chain establishes an arbitrarily long chain of trust between an issuing certificate and a child certificate. So instead of trusting certificates on a per-developer basis, we use the PKI concept of certificate chains to build a logical hierarchy of trust. Here’s a hypothetical example of a trust hierarchy based (roughly) on geography:
--------------------------
| rubygems@rubygems.org |
--------------------------
|
-----------------------------------
| |
---------------------------- -----------------------------
| seattlerb@seattlerb.org | | dcrubyists@richkilmer.com |
---------------------------- -----------------------------
| | | |
--------------- ---------------- ----------- --------------
| drbrain | | zenspider | | pabs@dc | | tomcope@dc |
--------------- ---------------- ----------- --------------
Now, rather than having 4 trusted certificates (one for drbrain, zenspider, pabs@dc, and tomecope@dc), a user could actually get by with one certificate, the “rubygems@rubygems.org” certificate.
Here’s how it works:
I install “rdoc-3.12.gem”, a package signed by “drbrain”. I’ve never heard of “drbrain”, but his certificate has a valid signature from the “seattle.rb@seattlerb.org” certificate, which in turn has a valid signature from the “rubygems@rubygems.org” certificate. Voila! At this point, it’s much more reasonable for me to trust a package signed by “drbrain”, because I can establish a chain to “rubygems@rubygems.org”, which I do trust.
The --sign option allows all this to happen. A developer creates their build certificate with the --build option, then has their certificate signed by taking it with them to their next regional Ruby meetup (in our hypothetical example), and it’s signed there by the person holding the regional RubyGems signing certificate, which is signed at the next RubyConf by the holder of the top-level RubyGems certificate. At each point the issuer runs the same command:
# sign a certificate with the specified key and certificate # (note that this modifies client_cert.pem!) $ gem cert -K /mnt/floppy/issuer-priv_key.pem -C issuer-pub_cert.pem --sign client_cert.pem
Then the holder of issued certificate (in this case, your buddy “drbrain”), can start using this signed certificate to sign RubyGems. By the way, in order to let everyone else know about his new fancy signed certificate, “drbrain” would save his newly signed certificate as ~/.gem/gem-public_cert.pem
Obviously this RubyGems trust infrastructure doesn’t exist yet. Also, in the “real world”, issuers actually generate the child certificate from a certificate request, rather than sign an existing certificate. And our hypothetical infrastructure is missing a certificate revocation system. These are that can be fixed in the future…
At this point you should know how to do all of these new and interesting things:
build a gem signing key and certificate
adjust your security policy
modify your trusted certificate list
sign a certificate
In case you don’t trust RubyGems you can verify gem signatures manually:
Fetch and unpack the gem
gem fetch some_signed_gem tar -xf some_signed_gem-1.0.gem
Grab the public key from the gemspec
gem spec some_signed_gem-1.0.gem cert_chain | \ ruby -rpsych -e 'puts Psych.load($stdin)' > public_key.crt
Generate a SHA1 hash of the data.tar.gz
openssl dgst -sha1 < data.tar.gz > my.hash
Verify the signature
openssl rsautl -verify -inkey public_key.crt -certin \ -in data.tar.gz.sig > verified.hash
Compare your hash to the verified hash
diff -s verified.hash my.hash
Repeat 5 and 6 with metadata.gz
OpenSSL Reference The .pem files generated by –build and –sign are PEM files. Here’s a couple of useful OpenSSL commands for manipulating them:
# convert a PEM format X509 certificate into DER format: # (note: Windows .cer files are X509 certificates in DER format) $ openssl x509 -in input.pem -outform der -out output.der # print out the certificate in a human-readable format: $ openssl x509 -in input.pem -noout -text
And you can do the same thing with the private key file as well:
# convert a PEM format RSA key into DER format: $ openssl rsa -in input_key.pem -outform der -out output_key.der # print out the key in a human readable format: $ openssl rsa -in input_key.pem -noout -text
There’s no way to define a system-wide trust list.
custom security policies (from a YAML file, etc)
Simple method to generate a signed certificate request
Support for OCSP, SCVP, CRLs, or some other form of cert status check (list is in order of preference)
Support for encrypted private keys
Some sort of semi-formal trust hierarchy (see long-winded explanation above)
Path discovery (for gem certificate chains that don’t have a self-signed root) – by the way, since we don’t have this, THE ROOT OF THE CERTIFICATE CHAIN MUST BE SELF SIGNED if Policy#verify_root is true (and it is for the MediumSecurity and HighSecurity policies)
Better explanation of X509 naming (ie, we don’t have to use email addresses)
Honor AIA field (see note about OCSP above)
Honor extension restrictions
Might be better to store the certificate chain as a PKCS#7 or PKCS#12 file, instead of an array embedded in the metadata.
Paul Duncan <pabs@pablotron.org> pablotron.org/
This module contains various utility methods as module methods.
The parent class for all constructed encodings. The value attribute of a Constructive is always an Array. Attributes are the same as for ASN1Data, with the addition of tagging.
Most constructed encodings come in the form of a SET or a SEQUENCE. These encodings are represented by one of the two sub-classes of Constructive:
OpenSSL::ASN1::Sequence
Please note that tagged sequences and sets are still parsed as instances of ASN1Data. Find further details on tagged values there.
int = OpenSSL::ASN1::Integer.new(1) str = OpenSSL::ASN1::PrintableString.new('abc') sequence = OpenSSL::ASN1::Sequence.new( [ int, str ] )
int = OpenSSL::ASN1::Integer.new(1) str = OpenSSL::ASN1::PrintableString.new('abc') set = OpenSSL::ASN1::Set.new( [ int, str ] )