rage VS melpa

I have already built this into a small feature in my app, but I do plan to integrate it deeper and bake it into the core functionality soon. Which should be another interesting problem to solve as the app has integrated client-side encryption using Age (rage (rage-wasm)). But that's for another day...

_o/ hi all, age author here!

The OP link is the spec, here's a few other things you might find interesting

- the Go reference implementation https://age-encryption.org

- the Go library docs https://pkg.go.dev/filippo.io/age

- the CLI man page https://filippo.io/age/age.1

- an interoperable Rust implementation by @str4d https://github.com/str4d/rage

- a YubiKey plugin by @str4d https://github.com/str4d/age-plugin-yubikey

- the draft plugin protocol specification (which we should really merge) https://github.com/C2SP/C2SP/pull/5/files?short_path=07bf8cc...

- a Windows GUI by @spieglt https://github.com/spieglt/winage

- a discussion of the authentication properties of age https://words.filippo.io/dispatches/age-authentication/

- a discussion of a potential post-quantum plugin https://words.filippo.io/dispatches/post-quantum-age/

- a password-store fork that uses age instead of gpg https://github.com/FiloSottile/passage (see also: how I use it with a YubiKey https://words.filippo.io/dispatches/passage/)

I just added rage (https://github.com/str4d/rage) support, which does support pinentry, see https://github.com/anticomputer/age.el#known-issues for an example of how to use rage instead.

Really appreciate this article. It's a little snarky but it hits the mark and encourages people to try Age, which is a pretty awesome little tool.

https://age-encryption.org/v1

I'm not convinced that whole-disk encryption is sensible for most threat models, but I use the built-in FileVault on macOS (under the reasoning that, at the very least, it can't really hurt).

On Linux, I use age[1] (specifically, rage[2]) to encrypt sensitive files. I wrote a secret manager that uses the latter as an encryption backend[3], and I use `rage-mount` to mount (read-only) views of encrypted archives.

[1]: https://github.com/FiloSottile/age

[2]: https://github.com/str4d/rage

[3]: https://github.com/woodruffw/kbs2

Watch the new pull requests to melpa: https://github.com/melpa/melpa/pulls

(require 'package) (add-to-list 'package-archives '("melpa" . "https://melpa.org/packages/") t) (package-initialize) (package-install 'use-package) (use-package exec-path-from-shell :ensure t :config (exec-path-from-shell-initialize)))

MELPA is definitely the biggest package archive, probably mostly on account of the lower barrier to entry compared to GNU ELPA (maybe the difference would have been less pronounced if NonGNU ELPA had been there from the beginning, but one can only speculate). MELPA has its own requirements for packages, but indeed copyright assignment to the FSF is not one of them.

I would suggest to start at reading the manual first. Then I would recommend reading the Melpa guidance, even if you do not plan to contribute your package to Melpa, since it contains very useful info about linting, writing your code etc.

The mxtoolbox link checks for SMTP blacklisting.. People won't be able to send mail from host with the IP address 178.128.185.1(which is the melpa.org webserver, not their mailserver, so everything's fine there).

Xah asked for his packages to be removed from MELPA a while back: https://github.com/melpa/melpa/issues/7755

Observe that package.el compile files when they are installed, and they are not compiled in any particular order (actually whatever directory-files returns, which is what OS returns). So if you have multiple files that depend on each other, it is something to think of. There are also some guidelines on how to structure your project on Melpa.