Autofirma is a java application used to sign digital documents.
It is the official application of the Spanish Government and as such it is
required to perform many online tasks with the Administration.
Details
Details
- Reviewers
- None
- Group Reviewers
Ports Committers
After installation you can execute autofirma. That one is a GUI app that allows you to digitally sign files. Unfortunately it is Spanish only.
Going to https://www.sededgsfp.gob.es/es/Paginas/TestAutofirma.aspx allows to test for the "webapp" version of the same application.
Diff Detail
Diff Detail
- Lint
Lint Skipped - Unit
Tests Skipped - Build Status
Buildable 68772 Build 65655: arc lint + arc unit
Event Timeline
Comment Actions
Not sure if it belongs in the java category, though... Perhaps security instead?
| java/autofirma/Makefile | ||
|---|---|---|
| 16 | Should this be JAVA_VERSION= 24+? | |
Comment Actions
Yeah, you're right. Dropping java as category.
| java/autofirma/Makefile | ||
|---|---|---|
| 16 | Unfortunately, the port does not work with openjdk25. Version 24 is the highest one where it works. | |
Comment Actions
I would probably also move it to the security subdirectory.
| java/autofirma/Makefile | ||
|---|---|---|
| 16 | Ok, that makes sense. Just checking :) | |
| java/autofirma/Makefile | ||
|---|---|---|
| 42 | Which bundle is that? | |
| java/autofirma/Makefile | ||
|---|---|---|
| 42 | Java comes with a bundle (cacerts) included. Bet it just works out of the box. | |
Comment Actions
Out of curiousity, since I see Mozilla and NSS here, does the library internally use NSS for something? Does it perform System#loadLibrary()? If yes, you might want to depend on NSS as well. Maybe you should investigate...
| security/autofirma/Makefile | ||
|---|---|---|
| 15 | Where do you use zip? | |
Comment Actions
This port made me curious, though I don't live in Spain:
- Why the hell did they pack a deb package in a ZIP file, clowns
- The data.tar has some interesting things you like have missed:
- Autofirma.js is for Firefox which will autoinject into prefs.js, it is user.js for Autofirma. You didn't handle this at all. It contains also a path which needs to be fixed for LOCALBASE
- What happened to autofirmaConfigurador.jar?
- Autofirma.png is located next to the JAR, will it be found in a different location?
- You did not patch afirma.desktop
- es.gob.afirma.metainfo.xml isn't required? ...and it clearly states that is depends on libnss3-tools
autofirma.jar contains directories linux/windows/osx (sic!) with a binary-bundled certutil, I bet this is libnss3-tools and maybe need to provide certutil.
Manual says "Versión completa de Java 8 o superior. Se recomienda el uso de Java 17.", why 24 then?
The code is here: https://github.com/ctt-gob-es/clienteafirma, you may need to patch the stuff: https://github.com/ctt-gob-es/clienteafirma/blob/5f877c0cdad198e0ca8354a569f2f53064b325c1/afirma-core/src/main/java/es/gob/afirma/core/misc/Platform.java and https://github.com/ctt-gob-es/clienteafirma/blob/master/afirma-keystores-mozilla/src/main/java/es/gob/afirma/keystores/mozilla/MozillaKeyStoreUtilities.java#L62.
¡What firma pain!
Comment Actions
Do I need to? The file is packed in case someone wants to install it in his/her home preferences.
- What happened to autofirmaConfigurador.jar?
That thing makes things worse. Sometimes it does not even work in Linux and breaks things.
- Autofirma.png is located next to the JAR, will it be found in a different location?
- You did not patch afirma.desktop
Done, thanks!
- es.gob.afirma.metainfo.xml isn't required? ...and it clearly states that is depends on libnss3-tools
Doesn't seem to. It works fine for me without it.
autofirma.jar contains directories linux/windows/osx (sic!) with a binary-bundled certutil, I bet this is libnss3-tools and maybe need to provide certutil.
I don't know the use of that. At least for my simple use (either stand alone or via web) it works fine for me.
Manual says "Versión completa de Java 8 o superior. Se recomienda el uso de Java 17.", why 24 then?
I tried to make it work from openjdk 18 until 23. The app didn't work. 24 works. 25 still doesn't work.
The code is here: https://github.com/ctt-gob-es/clienteafirma, you may need to patch the stuff: https://github.com/ctt-gob-es/clienteafirma/blob/5f877c0cdad198e0ca8354a569f2f53064b325c1/afirma-core/src/main/java/es/gob/afirma/core/misc/Platform.java and https://github.com/ctt-gob-es/clienteafirma/blob/master/afirma-keystores-mozilla/src/main/java/es/gob/afirma/keystores/mozilla/MozillaKeyStoreUtilities.java#L62.
I might need to patch that if at some point we want to support openjdk25 or directly upstream support for FreeBSD, but for now it works :-)
¡What firma pain!
Yes, it is.
Thanks for the thorough review!
Comment Actions
I think yes, for two reasons: The original Debian package does and you can't expect people to know how Firefox works internally.
- What happened to autofirmaConfigurador.jar?
That thing makes things worse. Sometimes it does not even work in Linux and breaks things.
Embarassing.
- Autofirma.png is located next to the JAR, will it be found in a different location?
- You did not patch afirma.desktop
Done, thanks!
- es.gob.afirma.metainfo.xml isn't required? ...and it clearly states that is depends on libnss3-tools
Doesn't seem to. It works fine for me without it.
autofirma.jar contains directories linux/windows/osx (sic!) with a binary-bundled certutil, I bet this is libnss3-tools and maybe need to provide certutil.
I don't know the use of that. At least for my simple use (either stand alone or via web) it works fine for me.
I would at least strip all of those foreign binaries from the JAR since they bloat the package w/o any benefit.
Manual says "Versión completa de Java 8 o superior. Se recomienda el uso de Java 17.", why 24 then?
I tried to make it work from openjdk 18 until 23. The app didn't work. 24 works. 25 still doesn't work.
Emberassing as well.
The code is here: https://github.com/ctt-gob-es/clienteafirma, you may need to patch the stuff: https://github.com/ctt-gob-es/clienteafirma/blob/5f877c0cdad198e0ca8354a569f2f53064b325c1/afirma-core/src/main/java/es/gob/afirma/core/misc/Platform.java and https://github.com/ctt-gob-es/clienteafirma/blob/master/afirma-keystores-mozilla/src/main/java/es/gob/afirma/keystores/mozilla/MozillaKeyStoreUtilities.java#L62.
I might need to patch that if at some point we want to support openjdk25 or directly upstream support for FreeBSD, but for now it works :-)
Highly recommend because a fork will be a pain. What you should do is to rain a GH issue to document all system properties and environment variables, I want to grep the source code to figure out why you set tthose.
¡What firma pain!
Yes, it is.
Thanks for the thorough review!
¡De nada!
Comment Actions
I don't follow here. The file is installed and its variables substituted. Or should I put the file elsewhere?
- What happened to autofirmaConfigurador.jar?
That thing makes things worse. Sometimes it does not even work in Linux and breaks things.
Embarassing.
- Autofirma.png is located next to the JAR, will it be found in a different location?
- You did not patch afirma.desktop
Done, thanks!
- es.gob.afirma.metainfo.xml isn't required? ...and it clearly states that is depends on libnss3-tools
Doesn't seem to. It works fine for me without it.
autofirma.jar contains directories linux/windows/osx (sic!) with a binary-bundled certutil, I bet this is libnss3-tools and maybe need to provide certutil.
I don't know the use of that. At least for my simple use (either stand alone or via web) it works fine for me.
I would at least strip all of those foreign binaries from the JAR since they bloat the package w/o any benefit.
I did not inspect the .jar files internally. In orther to do that, I assume I should unpack it and repack the .jar with only the relevant files?
Manual says "Versión completa de Java 8 o superior. Se recomienda el uso de Java 17.", why 24 then?
I tried to make it work from openjdk 18 until 23. The app didn't work. 24 works. 25 still doesn't work.
Emberassing as well.
The code is here: https://github.com/ctt-gob-es/clienteafirma, you may need to patch the stuff: https://github.com/ctt-gob-es/clienteafirma/blob/5f877c0cdad198e0ca8354a569f2f53064b325c1/afirma-core/src/main/java/es/gob/afirma/core/misc/Platform.java and https://github.com/ctt-gob-es/clienteafirma/blob/master/afirma-keystores-mozilla/src/main/java/es/gob/afirma/keystores/mozilla/MozillaKeyStoreUtilities.java#L62.
I might need to patch that if at some point we want to support openjdk25 or directly upstream support for FreeBSD, but for now it works :-)
Highly recommend because a fork will be a pain. What you should do is to rain a GH issue to document all system properties and environment variables, I want to grep the source code to figure out why you set tthose.
At some point I might do that, but I'm not sure about how those patches will be received for a niche OS like FreeBSD.
About the environment variables, I guess the most important one is the one that points to the location of the NSS libraries. At least there is that option. For what I understood of the code they look for libraries in standard linux paths.
¡What firma pain!
Yes, it is.
Thanks for the thorough review!
¡De nada!
:-)
Comment Actions
Not really, ${ZIP_CMD} can delete content out of a JAR without issues.
Manual says "Versión completa de Java 8 o superior. Se recomienda el uso de Java 17.", why 24 then?
I tried to make it work from openjdk 18 until 23. The app didn't work. 24 works. 25 still doesn't work.
Emberassing as well.
The code is here: https://github.com/ctt-gob-es/clienteafirma, you may need to patch the stuff: https://github.com/ctt-gob-es/clienteafirma/blob/5f877c0cdad198e0ca8354a569f2f53064b325c1/afirma-core/src/main/java/es/gob/afirma/core/misc/Platform.java and https://github.com/ctt-gob-es/clienteafirma/blob/master/afirma-keystores-mozilla/src/main/java/es/gob/afirma/keystores/mozilla/MozillaKeyStoreUtilities.java#L62.
I might need to patch that if at some point we want to support openjdk25 or directly upstream support for FreeBSD, but for now it works :-)
Highly recommend because a fork will be a pain. What you should do is to rain a GH issue to document all system properties and environment variables, I want to grep the source code to figure out why you set tthose.
At some point I might do that, but I'm not sure about how those patches will be received for a niche OS like FreeBSD.
Well, at least all relevant changes are documented in a PR, even if not upstreamed.