Crates.io | gpgrv |
lib.rs | gpgrv |
version | 0.4.1 |
source | src |
created_at | 2018-07-29 22:06:41.974069 |
updated_at | 2024-03-16 22:37:17.104321 |
description | Pure-Rust implementation of gpgv, to verify gpg signatures |
homepage | |
repository | https://github.com/FauxFaux/gpgrv |
max_upload_size | |
id | 76534 |
size | 581,070 |
gpgrv
is a Rust library for verifying some types of GPG signatures.
use std::io::{stdin, stdout, BufReader, Cursor, Seek, SeekFrom};
fn main() {
// load a keyring from some file(s)
// for example, we use the linux distribution keyring
let mut keyring = gpgrv::Keyring::new();
let keyring_file = Cursor::new(distro_keyring::supported_keys());
keyring.append_keys_from(keyring_file).unwrap();
// read stdin, verify, and write the output to a temporary file
let mut temp = tempfile::tempfile().unwrap();
gpgrv::verify_message(BufReader::new(stdin()), &mut temp, &keyring).expect("verification");
// if we succeeded, print the temporary file to stdout
temp.seek(SeekFrom::Start(0)).unwrap();
std::io::copy(&mut temp, &mut stdout()).unwrap();
}
This library does not care about expiry relative to system time.
If you want to handle expiry, you must do so yourself.
Yes, this is a very dangerous decision for cryptography code.
The intended usage for this code, working with real-world-computer-generated GPG signatures, is an unusual area of security in that many users will not care about expiry, or will be interested in validating against alternative clocks or time windows.
The author does not want to facilitate or encourage this, but respect that it is the decision for many users, including the system the author is integrating against.
Verifying signatures:
RSA
SHA1
and SHA2
(SHA-256
, SHA-512
).Signed "inline" messages, and detached signatures.
Armoured and unarmoured/binary.
Compression wrappers (added by gpg
for most messages)
Loading old-style keyrings (i.e. not keybox files)
Entirely safe Rust, no native code. Easy to build and portable.
MIT (or Apache2, or whatever!) licensed, not LGPL.
Simple, Rust-style API on streams (Read
/Write
).
A tiny amount of custom, low-risk crypto code. However, any crypto code can be wrong.
Limited, but growing, support for key and data formats.
(Intentionally) not constant time: Cannot be used for certain crypto applications. This is less important for signature verification with public keys.
gpgme
(LGPL) - bindings for native code, verbose API
rpgp
(MIT/Apache2) - serious implementation of plenty of pgp
sequoia-openpgp
(GPLv3) - serious implementation of plenty of pgp
I was using the gpgme
API, which works, but the API is painful,
and the linking/requirements are complicated.
sequoia
's license is wrong.
rpgp
has too many features, although it does seem to be nicely split into crates.
This crate is not testing an MSRV at this time, as clap
(used only in
examples) is not doing MSRV. If anyone has a use-case, please raise an issue,
and I'll see if clap
has improved, or if there's a convenient way to CI
an older release, without clap
.
MSRV bumps are some kind of semver bump, to be decided for 1.0.0
.
Licensed under either of
at your option.
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.