Thanks for all the effort that has gone into making Julia, and for these open conversations. As other’s have noted about themselves, I’ like to say I am not a Julia Guru and have not internalized the Pkg internals.
In good faith:
TL;DR: Pkg supports OpenBSD type secure distribution workflows, i.e using a signify|minisign type tools/library and permit self trusted updates/upgrades of packages.
Feature List:
- Optional: No change to existing packages unless the package author wants to. This proposal is for the Pkg tool to support the OpenBSD type secure workflows.
- Simple: Only support one algorithm; X25519/ED25519.
- Secure upgrades: Each signed-package will only upgrade if it contains the public key for the upgrade version
- Usable signatures: Signed packages will have signatures compatible with being verified by a human
- Notion of curated/trusted/maintained/active packages exist at the package level only and does not leak outside a package.
- Introduces package Signatory: Unsigned upstream packages can be freely adopted in secure workflows by signing (and maintaining/managing) the distribution of your own fork. Package names and versions can be the same and differ only by package signatory.
Feature detail. Quotes from here:
- Secure upgrades:
After each release of
OpenBSDa Julia package, we generate a new key pair for the release after next. That’s plus two. For example, after 5.6 was released, keys for 5.8 were generated. This way, the 5.8 keys are then included in the 5.7 release.
So, if you upgrade every release, you will have an unbroken chain of keys back to your initial installation. We don’t directly sign keys with keys, however, but the next key is implicitly signed by its inclusion in a signed release. Each key is tied to a release and only used for artifacts relating to that release.
- Usable signatures: The full signature can easily be verified/used.
Here’s the /etc/signify/openbsd-57-base.pub file from my system.
untrusted comment: openbsd 5.7 base public key
RWSvUZXnw9gUb70PdeSNnpSmodCyIPJEGN1wWr+6Time1eP7KiWJ5eAM
Additionally, Julia’s packaging system has an automatic secure-upgrade path established if we need to switch to a different algorithm than X25519/ED25519.
Adopt the X25519/ED25519 algorithm (alone) and put in place the data for the emergency when you have to abandon that choice because the algorithm is compromised.
This means Pkg will have put in place mechanisms to deal with the emergency that comes once in ‘the heat death of one universe’ 
This proposal should:
a. Isolate transport-protocol/source-of-package questions/issues from trust of package questions/issues. That is: I don’t care how a package gets to me or where it comes from. I care only that this is an upgrade from the same source (private key holder) as the current version.
b. Allow me to easily trust a package and once trusted, allow that package to contain the public keys that then permit auto-trusted updates/upgrades.
c. Restrict the notions of curated/maitained/active/trusted to the package level and not impose burdens on the community outside of that package’s maintainer(s). That is if you don’t want the burdens that come with saying this package is maintained/curated/active, don’t make it a signed package.
d. Enhance the no stdlib/base philosophy, but still allow peace-of-mind knowing that package upgrades will only come from the original maintainer Signatory.
e. Allow for the possibility of signed packages sharing name-version space. The full signature (e.g. RWSvUZXnw9gUb70PdeSNnpSmodCyIPJEGN1wWr+6Time1eP7KiWJ5eAM) breaks ties
Background, these discussions:
Discourse thread
Ephemaral slack thread
I doubt I could say more than the insight you will get from reading these sources, [1], [2], [3] and [4]
[1]: signify: Securing OpenBSD From Us To You
[2]: signify - sign and verify
[3]: Minisign by Frank Denis
[4]: GitHub - aperezdc/signify: OpenBSD tool to sign and verify signatures on files. Portable version.
Hope that helps?