Aquí figuran 5 versiones de age, desde 26 de diciembre de 2022 hasta la actual, 1.3.2. Cada una enlaza con los instaladores del propio desarrollador.
5 versiones en 4 años · unas 1,4 al año
| Versión | Fecha | Tamaño | Archivos |
|---|---|---|---|
| 1.3.2Última versión | 29 de agosto de 2026 | — | 64 bits ZIP Notas de la versiónage v1.3.2 is a minor release with a wide range of fixes and hardening improvements.
Some previously-accepted inputs are now rejected: headers over 2 MiB or 1024 recipients, malformed SSH keys in recipients files, and non-UTF-8 plaintext written to a terminal (force with -o -).
Pre-built binaries now cover windows/arm64 and darwin/amd64, and release archives include the compatibility plugins (age-plugin-pq, age-plugin-tag, and age-plugin-tagpq). |
| 1.3.1 | 28 de diciembre de 2025 | — | 64 bits ZIP Notas de la versiónv1.3.1 is a minor release to restore version injection from downstream package build processes.
See the v1.3.0 release notes for an overview of recent additions. |
| 1.2.1 | 18 de diciembre de 2024 | — | 64 bits ZIP Notas de la versiónThis release fixes a security vulnerability that could allow an attacker to execute an arbitrary binary under certain conditions.See GHSA-32gq-x56h-299c.Plugin names may now only contain alphanumeric characters or the four special characters +-._.Thanks to ⬡-49016 for reporting this issue. |
| 1.2.0 | 16 de junio de 2024 | — | 64 bits ZIP Notas de la versiónA small release to build the release binaries with a more recent Go toolchain, and to fix a couple CLI edge cases ( The Go module now exposes a plugin package that provides an age plugin client. That is, Recipient and Identity implementations that invoke a plugin binary, allowing the use of age plugins in Go programs.Finally, Recipients can now return a set of "labels" by implementing RecipientWithLabels. This allows replicating the special behavior of the scrypt Recipient in third-party Recipients, or applying policy useful for authenticated or post-quantum Recipients.
// RecipientWithLabels can be optionally implemented by a Recipient, in which
// case Encrypt will use WrapWithLabels instead of Wrap.
//
// Encrypt will succeed only if the labels returned by all the recipients
// (assuming the empty set for those that don't implement RecipientWithLabels)
// are the same.
//
// This can be used to ensure a recipient is only used with other recipients
// with equivalent properties (for example by setting a "postquantum" label) or
// to ensure a recipient is always used alone (by returning a random label, for
// example to preserve its authentication properties).
type RecipientWithLabels interface {
WrapWithLabels(fileKey []byte) (s []*Stanza, labels []string, err error)
} |
| 1.1.1 | 26 de diciembre de 2022 | — | 64 bits ZIP |