-
-
Notifications
You must be signed in to change notification settings - Fork 112
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
apksigner & jsign with AWS? #226
Comments
Could you try again with the latest build: https://github.com/ebourg/jsign/actions/runs/9286970939/artifacts/1548458586 |
The latest build fixes the issue above, it almost works, but I found that when I want to pass the certificate file that's going to be used for signing the build and now that's where I'm getting stuck (forgot to add that arg in above command):
This above doesn't work as I need the certificate:
Maybe it's simple, but I couldn't quite figure out a way to do pass jsign the certfile name. I've tried:
Looking at it logically I guess we are actually running apksigner and can only use the arguments it supports and it doesn't seem to support any --ks-cert* option (it does support a --cert option, but it uses this exclusively with local keyfiles only, it's not used for plugins), The apksigner does mention a --cert option when using jsign as a keystore provider but in the latest apksigner this does not actually work.
So instead I guess we need to pass the certfile to use for signing in a different way back to jsign. Either as part of |
For reference for others reading this the AWS KMS doesn't store certificates at all, only public and private keys. If you want to use it for signing with any kind of certificate that's signed by the key, you'll have to generate a signed certificate, then use that as a file, then store this certificate out of band somewhere. Amazon does have some (expensive) solutions such as amazon Private CA which can handle storing certificates, but not their low cost KMS product this plugin uses. Also for others who are going down the same track, if you want to quickly export credentials in a jsign compatible format, you can use this one liner to set the JSIGN_AWS_CREDS environment variable: |
@ebourg I just found that this rejected) PR #215 contains a fix which can exactly fix this issue: Essentially, with the above fix we can pass the certificate file as a system parameter:
If we don't use above, we could change the name of the keystore to be something like "region=us-east-1:certfile=certificate.pem" via the --provider-arg. This might be slightly more complex though. |
@hongkongkiwi Thank you for the analysis. I didn't realize that the I see several approaches to this problem:
|
Idea (1) using the system property wouldn't cause a conflict in my case as I'm calling it each time with the specific property set in a Lambda. But I see what you mean, it's not going to be idea for some people's batch use cases. Probably another option is better. Ideally, I think (3) is a good move. This seems like a bug and other tools support this just fine. Google uses the sun PKCS11 plugin along with a google cloud pkcs11 implementation. This uses a separate config file to setup the parameters for the sun PKCS11 plugin. That's why they havn't really come across this probably since the sun pkcs11 plugin has it's own way of configuring. I think implementing (2) is a also good idea and something that's relatively straightforward and can be done without assistance from third parties. Perhaps it could be done in a way that is backwards compatible. For example first we check if we have key=value then we can pass multiple keys based on jsign's normal input parameters. If no key=value exists then just fallback to existing method of processing the alias. That could be "alias=abc|certfile=abc.pem". This would assume that aliases don't normally contain a pipe character or equals character (not sure about this? Methods 4, 5, 6 seem to have a high development burden and don't address other possible tools which may have the same issue (although I don't know any of those). Google seems to regularly develop and modify apksigner, especially as they are on signing version v4 now. I like the idea that I can just use the latest version of that alongside the latest version of jsign. This is a great product and I don't think it makes sense to add a lot of development distraction for keeping upto date with apksigner. |
Looks like this issue affects all keystore types when using apksigner and jsign via JCA, not only AWS. I'm trying to use JKS keystore type as a JCA plugin, but it also has the same issue. |
What exception do you get with a JKS keystore? |
I just wanted to say this comment was very helpful! What I ended up doing is creating a CSR with openssl using a private key and then storing that key material in KMS. Using the modified code from PR-215 I was able to then sign an APK with the cert and the key in KMS. |
Hi there,
I'm struggling a little bit to get this working. I'd like to use JSign to sign an apk (using apksigner) using an AWS KMS key.
Here's what I've got (not, I've substituted the jar paths here, but locally I'm using the full path to the jar file).
In this case,
CREDS="<ACCESS_KEY>|<SECRET_KEY>|<SESSION_TOKEN>"
as specified in the docs.Is this the correct usage? I'm getting this error:
The text was updated successfully, but these errors were encountered: