I've been moving all of the projects I still maintain to Java 9
modules. In order
to do this, however, I've needed to assist third party projects upon
which I have dependencies to either modularize their projects or
publish Automatic-Module-Name
entries in their jar
manifests. If
you try to specify a dependency on a project that either hasn't been
modularized or hasn't published an Automatic-Module-Name
entry,
you'll see this when building with Maven:
[WARNING] ******************************************************************************************************************** [WARNING] * Required filename-based automodules detected. Please don't publish this project to a public artifact repository! * [WARNING] ********************************************************************************************************************
The reasons for this are documented on Stephen Colebourne's blog.
Here's a table of all of the third party projects upon which I depend, and an indication of the current state of modularization (I'll try to keep this updated as projects are updated):
Project | State | Updated |
---|---|---|
fastutil | Considering | 2018-02-07 |
jcpp | Considering | 2018-02-08 |
ed25519-java | Considering | 2018-02-09 |
LWJGL | Fully Modularized | 2018-02-07 |
Dyn4j | Fully Modularized | 2018-02-07 |
protobuf | Ignored? | 2018-02-07 |
antlr | In Progress | 2018-02-11 |
autovalue | In Progress | 2018-02-07 |
rome | In Progress | 2018-02-07 |
JGraphT | Automatic Module Names (Full modularization in progress) | 2018-02-11 |
Vavr | Automatic Module Names | 2018-02-07 |
commonmark-java | Automatic Module Names | 2018-02-07 |
javapoet | Automatic Module Names | 2018-02-07 |
xom | Unclear | 2018-02-07 |
Generally, if a project isn't planning to either modularize or publish automatic module names, then I'm looking for a replacement for that project.
I'm having trouble deploying packages to Maven Central. The repository claims that it cannot validate the signatures I provide. I've filed a bug but haven't gotten a response. I'm wondering if it's down to me switching to Curve25519 PGP keys...
New PGP keys have been published.
Fingerprint | UID ----------------------------------------------------------------------------------- B84E 1774 7616 C617 4C68 D5E5 5C1A 7B71 2812 CC05 | Mark Raynsford (2018 personal) F8C3 C5B8 C86A 95F7 42B9 36D2 97E0 2011 0410 DFAF | io7m.com (2018 release-signing)
See the the previous blog post:
$ gpg --recv-keys 8168DAE22B15D3EDC722C23D0F15B7D06FA80CB8 $ wget -r http://blog.io7m.com $ cd blog.io7m.com $ gpg < checksum.asc | sha512sum --check
Better.
This blog was designed to be verifiable:
$ gpg --recv-keys 8168DAE22B15D3EDC722C23D0F15B7D06FA80CB8 $ wget -r http://blog.io7m.com $ find blog.io7m.com -name '*.asc' -exec gpg --verify {} \;
Note that the 8168DAE22B15D3EDC722C23D0F15B7D06FA80CB8
key ID assumes
you're reading this in 2017. By the time 2018 comes around, this blog
will be signed with a new key (and a new one for each passing year).
Possible points of failure:
A malicious actor gets the remote keyserver to serve a
different key than the one with fingerprint
8168DAE22B15D3EDC722C23D0F15B7D06FA80CB8
. Does gnupg
verify that a received key had the fingerprint that the
user specified on the command line? What if the user
specified my name and key comment instead of a fingerprint?
The actor at this point might be able to convince you that
the signatures on files on blog.io7m.com
are invalid. It
might be able to convince you that its own key is mine.
A malicious actor modifies the files and signatures when
wget
downloads them. The actor can't generate valid signatures
for the key 8168DAE22B15D3EDC722C23D0F15B7D06FA80CB8
(unless
it can break RSA), but it can try to convince you that its own
key is actually my key and therefore have you trust that the
data you're seeing is unmodified and was signed by me. If the
actor managed to perform step 1 above, then you're completely
compromised.
A malicious actor removes some of the signatures. If you didn't
know exactly how many pages there should be, you'd not notice
if gpg
didn't verify one of them.
Step 1 has no technical solution; you need to verify the keys you receive and check the signatures on those keys assuming they come from other keys that you trust. If you're lucky, there is a chain of signatures leading to a key that you do trust with certainty. I have yearly expiring keys, and I sign each new year's keys with the old keys. Unless my keys have been compromised yearly, there's a reasonable chance that the keys you see are mine!
Step 2 is partially mitigated by https
, assuming that the actor
doesn't have backdoor access to the CA issuing the certificate.
The actor can have the CA issue a new certificate, redirect you
to a server that the actor controls, decrypt the traffic, modify
it, and then re-encrypt it. You'd never know anything was wrong.
Step 3 is manually mitigated by reading the posts by year
page and checking that you have at least as many signatures as
pages. I may start publishing a CHECKSUMS
file that just contains
signed SHA512
hashes of every file on the site.
I'm considering using keybase in addition to publishing PGP keys on the public keyservers. I don't do social media, so I'm not sure how much it'd apply to me. I do use GitHub heavily though.