Hi guys, Adam, James: I am afraid something is not right around the keys and i was unable to verify :(
Let me share my steps and findings: - Downloaded "apache-fineract-1.11.0-binary.tar.gz.asc” and "apache-fineract-1.11.0-binary.tar.gz”. Run "gpg --verify apache-fineract-1.11.0-binary.tar.gz.asc apache-fineract-1.11.0-binary.tar.gz” on them gave the following: gpg: Signature made Sat 1 Mar 02:06:12 2025 GMT gpg: using EDDSA key BD58EA9F85201ADB52CFC0444F169FF263F5F98E gpg: Can't check signature: No public key Run "gpg --keyserver keys.openpgp.org --recv-key BD58EA9F85201ADB52CFC0444F169FF263F5F98E” gpg: key 4F169FF263F5F98E: no user ID <- THIS LOOKS BAD! gpg: Total number processed: 1 Run "gpg --verify apache-fineract-1.11.0-binary.tar.gz.asc apache-fineract-1.11.0-binary.tar.gz” once ag gpg: Signature made Sat 1 Mar 02:06:12 2025 GMT gpg: using EDDSA key BD58EA9F85201ADB52CFC0444F169FF263F5F98E gpg: Can't check signature: No public key I have tried to import the KEYS from https://dist.apache.org/repos/dist/dev/fineract/KEYS but got the very same issue that Victor mentioned. I have taken a look on the patch that was shared by Adam Monsen, but i am not comfortable with that since it contains many changes compared to the uploaded file! Also the previous PGP keys and the one that was uploaded by James? not even similar in length. Are we sure the proper keys were created? Regards, Adam > On 2025. Mar 3., at 17:45, VICTOR MANUEL ROMERO RODRIGUEZ > <victor.rom...@fintecheando.mx> wrote: > > @Adam Monsen <mailto:amon...@mifos.org> I found that the testing on > binaryDistTar task is taking my JVM locale (which is es-MX), so then changing > the locale to en-US fixes it. > > Caused by: PlatformApiDataValidationException{errors=[The parameter > `startDate` is invalid based on the dateFormat: `dd MMMM yyyy` and locale: > `en` provided:]} > at > app//org.apache.fineract.portfolio.loanaccount.service.reaging.LoanReAgingValidatorTest.lambda$testValidateReAge_ShouldThrowException_WhenLoanIsNotActive$13(LoanReAgingValidatorTest.java:361) > Caused by: java.time.format.DateTimeParseException: Text '08 abril 2025' > > El lun, 3 mar 2025 a las 11:36, Adam Monsen (<amon...@mifos.org > <mailto:amon...@mifos.org>>) escribió: >> Hi Victor, thank you for helping me with this! >> >> Others: we need help from at least two more people to get this release out >> the door. Please: >> >> 1. download the release candidate artifacts and verify their integrity >> 2. run a build using only the source tarball and the recommended JDK >> 3. start up a Fineract server using the war in the binary tarball >> >> These are just suggestions and I apologize for being brief/vague, I'm >> looking forward to helping out with documenting and detailing this process. >> If you have feedback on the best way to perform these steps, please share. >> >> Victor wrote: >>> The attached file contains the commands executed and shows checksum error >>> verification for the KEYS file. >> >> Good catch! I was able to reproduce this. The "invalid armor header" / >> "cabecera de armadura inválida", "CRC error" / "Error en suma de >> comprobación", and "[don't know]: invalid packet (ctb=40)" messages are all >> due to one missing newline in the last key. I hadn't run into this error >> previously because I think James gave me that key directly when we were able >> to do a mini keysigning party in person and it was properly formatted. But >> yeah, that's an invalid key there. Probably a copy/paste error or something. >> >> I'd like to improve this KEYS file to fix the broken key, add some >> documentation at the top, and use consistent formatting. James or Aleks, >> will you please review, apply and commit the attached patch against >> https://dist.apache.org/repos/dist/dev/fineract/KEYS at r71016? >> >> Regarding verifying the release candidate, I don't think there's much value >> in running the srcDistTar task, but I suppose it doesn't hurt. The >> binaryDistTar task is a bit more useful since it does build the code and run >> some basic tests. I'm not sure exactly what failed there but I'd say start >> with the recommended JDK version and try running the build from a very clean >> environment. For example, I've found I need to sometimes run `git clean >> -fdx` remove all of ~/.gradle to get a successful Fineract build and/or test >> run. I think this helps get rid of cached artifacts or old/bad dependencies >> or something. >> >> I wrote: >>> The help I'm seeking is for PMC members to fetch and verify these artifacts >>> are valid, following "Step 9: Verify Distribution Staging" from the >>> official docs (current-enough copy at >>> https://fineract.apache.org/docs/current/ ) and >>> https://www.apache.org/legal/release-policy.html . Additionally, my >>> unofficial suggestions are currently living at >>> https://github.com/meonkeys/fineract-asf-release-checklist/ (there's some >>> overlap and it's a work in progress, but I've got some good ideas there). >>> >>> I'm working on updates to the docs to reflect what worked and didn't for us >>> today.
