2,781,986 events, 1,404,497 push events, 2,245,142 commit messages, 158,237,496 characters
- EUREKA: after two-weeks of low-key fretting, worrying, bewilderment, frustration, and finally, a tearful breakdown earlier this afternoon, I re-learned something which I probably needed a reminder about: not to get all "typey" and try to fix "errors" (read: stupid browser/devtools warnings) with fixes I don't understand the implications of (putting "useRef" inside my SideDrawer for instance, which turned out the be the breaking change which has destroyed the dynamic sidebar rendering ever since I discovered said bug DURING MY FINAL CAPSTONE SHOWCASE PRESENTATION, TRULY AN EPIC FAIL); let this all serve as a timely reminder not to just keep manically typing when you've had too much coffee.
- side-drawer navigation renders and works more or less as it should/as it did before, thankfully
- oh and I removed App.css, as I realized it wasn't doing a goddamn thing; hopefully this isn't another one of those changes I do where I don't see the disastrous consequences which await me.
- Go get outside, get off your computer; go draw something or talk to a person about something you both are curious about.
<3, vita xoxo
Add JNI lib for interacting with macOS security framework (#15)
The security commandline tool on macOS is a horrible tool.
It has a very ugly interface and most commands have weird ways of
returnning values. Sometimes stuff gets pushed to stdout and
sometimes to stderr. Not all features are supported, like getting
the actual status of a keychain. To have more control over the
execution and the output I decided to move some of the core keychain
handling logic into a JNI lib.
At the moment this means most APIs that provide basic keychain
logic (create, lock, unlock, etc) are now implemented with
a JNI lib. The rest of the functionality is still provided with
the security cli wrapper commands.
JNI on its own is a tough bit of software. I decided to use the
[nokee] gradle plugin suite to build package a JNI jar with a native
libraty written in pure c. This is all contained in a seperate
gradle subproject.
┌────────────────┐
│ │
│ macos-security │
│ │
└───────┬────────┘
│
│ ┌────────────────────┐
│ │ │
└───────►│ macos-security-jni │
│ │
└────────────────────┘
This new project contains two major wrappers.
- MacOsSecurity
- KeychainRef
The MacOsSecurity class is the main native interface and provides
the raw JNI methods. I decided to wrap the functions provided by
the apple Security Framework as close as possible without to much
JNI back and forth. Means when possible only use scalar parameters
and simple types JNI supports out of the box.
KeychainRef on the other hand contains methods that allow to pass
more jave natural objects like File, List<> etc. These will
be translated back and forth. My main intention is that
MacOsSecurity should not be used directly from consuming libraries.
The KeychainRef object is also interesting because of a second fact.
This object is mainly an interface. It's the main object returned
and or passed to MacOsSecurity. The kechain references in the
Security Framework are memory managed with a reference counting
model. The moment we pass a keychain ref to JAVA land we are responsible
of releasing it again. To make this as easy as possible I decided
to create this interface. The c code will instanciate an object
which implements this interface which is not constructable from Java.
This object has a finalizer which calls into JNI again to release
the reference. This makes it easy to use these references without
thinking to much about the underlying memory management model.
This patch will introduce breaking API changes. I thought about this
long and think to leverage this new JNI interface best we should use
the KeychainRef as the main handle to pass keychain references.
The old API used File objects since keychains are just files on the
harddisc. But I like the fact to use a strict datatype to describe
a keychain rather that a generic File object. I updated everything
to use the new object. From the outside it is quite easy to move from
the File based API to the new one. The KeychainRef interface has
static methods to either create or open (get) keychain references from
files. The underlying files don't have to exists to fetch a valid
KeychainRef.
I updated also the publish flow slightly since we need to publish
two jars at the same time. I didn't want to open a new repo for
the JNI part as this belongs together in a single repo anyways.
I moved the main publish configuration for gradle into a file
publish-helper.gradle which is sourced by the two gradle projects.
The rest is taken care of by the maven-publish/nexus publish plugins.
This patch is rather big for my taste. I don't think breaking it up makes a lot of sense here.
- ![ADD] ![GRADLE] subproject
macos-security-jni - ![ADD]
JNIlibrary to expose Security Framework functions to Java - ![BREAK] Use
KeychainRefas the base keychain objects rather thanFile - ![IMPROVE] publish to publish multiple projects (jars) at the same time
fixed the code that reads inputs.txt
holy fucking shit was i drunk when i wrote that the first time around? i copied and pasted the same code and assigned the completely wrong values.
jdk8 sucks: Work around strange issue with debian alternatives system
For some reason, the exact issue here https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863199 is happening and is fixed by the same workaround. It is an ugly hack, but since we are using containers like VMs, we have to make the OS happy.
jdk11 (buster) appears unaffected by the problem.
At least the devs are aware that there are interesting issues and dependencies in Debian java land https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940297
Change-Id: Ia71c77e8bf271dbb319768ae90cf6abc25fcd056