AVRDUDE 8.1 released

[stefanrueger]

Version 8.1 of AVRDUDE has just been released:

• Support for new devices
  • AVR128DA28S, AVR128DA32S, AVR128DA48S, AVR128DA64S
  • AVR64DA28S, AVR64DA32S, AVR64DA48S, AVR64DA64S
  • AVR32DA28S, AVR32DA32S, AVR32DA48S
  • AVR32EB14, AVR32EB20, AVR32EB28, AVR32EB32
  • AVR32SD20, AVR32SD28, AVR32SD32
• Support for new programmers
  • pickit5* over and above pickit5_updi
  • pickit_basic* = pickit_basic_mplab*
  • pickit4_mplab*, pickit4_dw
  • snap_mplab*, snap_dw
• A new concept of autogenerated files (urboot:)
• Bug fixes (fewer than usual, probably owing to improved testing capabilities in the team eradicating bugs early on)

The project now has very few open issues that are considered bugs, shows a steady improvement in CI building, continues to stay close to the coal face for cutting edge programmers and parts whilst remaining backward compatible with no longer supported operating systems, outdated programmers and out-of-production parts.

Particular thanks go to @mcuee, @MCUdude, @MX682X, @dbuchwald, @dl8dtl and countless others for advice, testing, new contributions, sharing observed bugs and ideas.

Enjoy :)

[mcuee]

There are two issues related to github action release deployment.

• GitHub deploy action for avrdude failed to run #2038 --> no automatic upload of the main Windows MSVC build binaries
• github avrdude_packing_release action failed #2039 --> binary archives are not generated (only first run is working, other runs will not work).

I will upload the binaries manually. I was doing that for 8.0 release anyway.

[mcuee]

There are two issues related to github action release deployment.

• GitHub deploy action for avrdude failed to run #2038 --> no automatic upload of the main Windows MSVC build binaries
• github avrdude_packing_release action failed #2039

@stefanrueger

Ideas to prevent such issues in the future -- maybe it is a good idea to always tag an RC release before the final release.

We can update the release checklist here.
https://github.com/avrdudes/avrdude/wiki/Release-Procedure

[mcuee]

@stefanrueger, @MCUdude and @dl8dtl

I have uploaded the binaries. I will assemble a Windows Python binding zip file later and write a help file to tell the user how to use it.

[mcuee]

@stefanrueger

One small thing, just wondering if you want to mention the GPG keys you used for the signature.

MINGW64 /c/work/avr/avrdude_bin/github_bin_v81
$ gpg --verify avrdude-8.1.zip.sig avrdude-8.1.zip
gpg: Signature made Mon, Jun 23, 2025  9:11:35 PM CST
gpg:                using RSA key 29E2E266E43A84A85F1F150DB0B4F1FD86B1EC55
gpg:                issuer "stefan.rueger@urclocks.com"
gpg: Can't check signature: No public key

$ gpg --verify avrdude-8.1.tar.gz.sig avrdude-8.1.tar.gz
gpg: Signature made Mon, Jun 23, 2025  9:11:44 PM CST
gpg:                using RSA key 29E2E266E43A84A85F1F150DB0B4F1FD86B1EC55
gpg:                issuer "stefan.rueger@urclocks.com"
gpg: Can't check signature: No public key

Reference:
https://github.com/libusb/libusb/wiki#downloads

• Document PGP release signature usage libusb/libusb#1469

[stefanrueger]

The public key can be obtained from the keyserver keys.openpgp.org. Alternatively, it can be imported via

$ gpg --keyserver keys.openpgp.org --recv-keys 45684AB70D286F63

[mcuee]

@stefanrueger

This is what I get. Basically it says the signing is good but they can not verified that the signature really belongs to you. :-)

MINGW64 /c/work/avr/avrdude_bin/github_bin
$ gpg --keyserver keys.openpgp.org --recv-keys 45684AB70D286F63
gpg: keybox '/home/xiaof/.gnupg/pubring.kbx' created
gpg: /home/xiaof/.gnupg/trustdb.gpg: trustdb created
gpg: key 45684AB70D286F63: public key "Stefan Rueger <stefan.rueger@urclocks.com>" imported
gpg: Total number processed: 1
gpg:               imported: 1

$ gpg --verify avrdude-8.1.zip.sig avrdude-8.1.zip
gpg: Signature made Mon, Jun 23, 2025  9:11:35 PM +08
gpg:                using RSA key 29E2E266E43A84A85F1F150DB0B4F1FD86B1EC55
gpg:                issuer "stefan.rueger@urclocks.com"
gpg: Good signature from "Stefan Rueger <stefan.rueger@urclocks.com>" [unknown]
gpg: WARNING: The key's User ID is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 8FBD C995 56F7 C22A 77DC  3E11 4568 4AB7 0D28 6F63
     Subkey fingerprint: 29E2 E266 E43A 84A8 5F1F  150D B0B4 F1FD 86B1 EC55

[mcuee]

@stefanrueger
But I guess this is as good as it can be now, without paying for a code signing key.

It is the same for libusb from @tormodvolden
https://github.com/libusb/libusb/releases/tag/v1.0.29

FYI: the more stringent Windows driver signing will require a more expensive and more stringent Extended Validation (EV) code signing certificates. Last time we got the donation to get such EV certificate for libusbK project. But we gave up later as it was more and more difficult to get an EV certificate for individual developers. For libusb-win32 project, the current developer has a valid EV certificate as part of his business.

MINGW64 /c/work/libusb/libusb
$ gpg --import KEYS
gpg: key 2C80FF56C6830A0E: 2 signatures not checked due to missing keys
gpg: key 2C80FF56C6830A0E: public key "Tormod Volden <tormod.volden@gmail.com>" imported
gpg: Total number processed: 1
gpg:               imported: 1
gpg: no ultimately trusted keys found

$ gpg --keyserver hkp://keys.gnupg.net --recv-keys C68187379B23DE9EFC46651E2C80FF56C6830A0E
gpg: key 2C80FF56C6830A0E: "Tormod Volden <tormod.volden@gmail.com>" not changed
gpg: Total number processed: 1
gpg:              unchanged: 1

$ gpg --keyserver keyserver.ubuntu.com --recv-keys C68187379B23DE9EFC46651E2C80FF56C6830A0E
gpg: key 2C80FF56C6830A0E: "Tormod Volden <tormod.volden@gmail.com>" not changed
gpg: Total number processed: 1
gpg:              unchanged: 1

$ cd /c/work/avr/avrdude_bin/github_bin/

$ gpg --verify libusb-1.0.29.tar.bz2.asc
gpg: assuming signed data in 'libusb-1.0.29.tar.bz2'
gpg: Signature made Mon, Jun  2, 2025  2:40:03 AM +08
gpg:                using RSA key 9C7EA94939C69C4FBC3DBFA8AA0639079EFB61B9
gpg: Good signature from "Tormod Volden <tormod.volden@gmail.com>" [unknown]
gpg:                 aka "Tormod Volden <debian.tormod@gmail.com>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: C681 8737 9B23 DE9E FC46  651E 2C80 FF56 C683 0A0E
     Subkey fingerprint: 9C7E A949 39C6 9C4F BC3D  BFA8 AA06 3907 9EFB 61B9

$ gpg --verify libusb-1.0.29.7z.asc
gpg: assuming signed data in 'libusb-1.0.29.7z'
gpg: Signature made Mon, Jun  2, 2025  4:10:20 AM +08
gpg:                using RSA key 9C7EA94939C69C4FBC3DBFA8AA0639079EFB61B9
gpg: Good signature from "Tormod Volden <tormod.volden@gmail.com>" [unknown]
gpg:                 aka "Tormod Volden <debian.tormod@gmail.com>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: C681 8737 9B23 DE9E FC46  651E 2C80 FF56 C683 0A0E
     Subkey fingerprint: 9C7E A949 39C6 9C4F BC3D  BFA8 AA06 3907 9EFB 61B9

[stefanrueger]

not verified that the signature really belongs to you

Yes, the perennial problem of sharing public keys. What has been missing is the assertion in the release notes how to obtain the signing key. I've done so now. This is as good as it gets considering that the release artifacts are distributed by github (straight from the horse's mouth). Technically, the .sig files are hashes encrypted with the key of the signer. As github already publishes the sha256 hash with the assets, the .sig file doesn't actually add more trust, security etc, only the convenience of easier verification.

Trust becomes an issue again when packagers distribute downloads from github. Then the problem arises to link the signature key of the .sig file to one that's been used by one of the project maintainers. However, I consider it the package distributor's job to sign the downloads from github when they distribute the files. As they might want to add (or remove, alter) files from the githib artifacts, nobody else can do the signing.

[mcuee]

Issues raised by @MCUdude to the Arduino avrdude-packing project. The main advantage for the Arduino flavor of avrdude binaries is that the macOS build is signed with an Apple Developer signature which makes it easier to run under macOS.

• Make an 8.1 release arduino/avrdude-packing#35

[stefanrueger]

It should be OK if one of us signs the binaries that we distribute. I have done so for those that github provides: Source code (zip), which results in the same as avrdude-8.1.zip and Source code (tar.gz), which is the same as avrdude-8.1.tar.gz.

[mcuee]

It should be OK if one of us signs the binaries that we distribute. I have done so for those that github provides: Source code (zip), which results in the same as avrdude-8.1.zip and Source code (tar.gz), which is the same as avrdude-8.1.tar.gz.

Take note normal signature does not work for Apple binaries.

Discussions for the avrdude 8.0 release.

• AVRDUDE 8.0 released #1912 (comment)

From @MCUdude

@mcuee I'm thinking about bunding the statically built Avrdude binaries to a new version of my Arduino cores. However, I can't execute the macOS binary, because it has been released by an unauthorized developer. What to do? And how did @umbynos get around this when building "Arduino flavored" Avrdude binaries?

From me:

@MCUdude

You have to sign up with Apple Developer program and then you can sign the binaries with the Code-Signing Certificate.

Reference:
https://github.com/arduino/avrdude-packing/blob/main/.github/workflows/release.yml

The annual fee is US$99.
https://developer.apple.com/support/enrollment/

From @umbynos, unfortunately he is no longer with Arduino.

Hey, yeah, is because of code-signing. We got a certificate from Apple Dev program and we use that to sign binaries (CLI/IDE)..

[MCUdude]

It would be great if we, the Avrdude developers, could provide everything ourselves. By this, I mean dynamically and statically built binaries (with all dependencies, including libserialport) and signed binaries that work on OSes that require them, like macOS.

I have no problems with donating money to get signed binaries for macOS that I can bundle with my Arduino cores. However, it looks like we're going to be releasing a new version about once a year, so paying $99 just to sign binaries once a year is a bit pricey. Isn't there a service we could use to get our macOS builds signed for a one-time fee?

[mcuee]

However, it looks like we're going to be releasing a new version about once a year, so paying $99 just to sign binaries once a year is a bit pricey. Isn't there a service we could use to get our macOS builds signed for a one-time fee?

@MCUdude

I believe there is no such legal service available -- as it may well be against the Apple developer license.

[mcuee]

@MCUdude

We may try ad-hoc code signing as mentioned below.

• https://github.com/orgs/Homebrew/discussions/3614
• https://stories.miln.eu/graham/2024-06-25-ad-hoc-code-signing-a-mac-app/

[mcuee]

@MCUdude

Homebrew formula has been updated. Unfortunately, no libserialport support yet.
https://github.com/Homebrew/homebrew-core/blob/506c5d80aa73e259da45e0192473103f4668ce87/Formula/a/avrdude.rb

[mcuee]

Homebrew formula has been updated. Unfortunately, no libserialport support yet. https://github.com/Homebrew/homebrew-core/blob/506c5d80aa73e259da45e0192473103f4668ce87/Formula/a/avrdude.rb

@chenrui333
It seems to me you are the active maintainer for the avrdude Homebrew formula, it would be good to add libserialport as a dependency. Thanks.

[mcuee]

Good reference for the adoption of avrdude 8.1 release.
https://pkgs.org/download/avrdude
https://repology.org/project/avrdude/versions

As of now, Arch Linux, macOS Homebrew, scoop (Windows) and Termux (Android) are already using avrdude 8.1 release.

[stefanrueger]

Neater display: https://repology.org/badge/vertical-allrepos/avrdude.svg?columns=4&minversion=7.3

It took Ubuntu 10 years to move from 6.x to 7.x, so predicting Ubuntu users will get AVRDUDE 8.x in April 2034.