| Summary: | New package: app-crypt/parcimonie to mitigate an information leak | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Chicago <chicago> |
| Component: | New packages | Assignee: | Default Assignee for New Packages <maintainer-wanted> |
| Status: | UNCONFIRMED --- | ||
| Severity: | enhancement | CC: | chicago |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://gaffer.ptitcanardnoir.org/intrigeri/code/parcimonie/ | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
There are some oddities about this package. The web site listed has not been updated since 2011, although there is plenty of activity in the git repository. I cannot find any tarballs, but an ebuild can easily enough pull from the appropriate git tag for a released version. However, installing requires the Perl CPAN module Dist::Zilla, which has only a (~) version in the tree, and, for me (with a fairly up to date Perl) that would require installing over 100 new packages, mostly perl modules, and also requires updating perl to a (~) version and accepting dozens of (~) perl modules. Would enough people find this acceptable, that it's worth proceeding? Another approach would be writing an ebuild to use a Debian package - would that count as a "binary" ebuild, even though all the code is Perl? |
Hello, Please develop an ebuild for Parcimonie and add it into the tree. OpenPGP Best Practices as suggested at riseup.net, https://riseup.net/en/security/message-security/openpgp/best-practices/#refresh-your-keys-slowly-and-one-at-a-time indicate there is an information leak when using "/usr/bin/gpg --refresh-keys" which many users implement via cron. A secure alternative to request updates from a keyserver for keys that already exist on the local keyring would be nice to have. Best Regards, -Chicago