Apt repositories support authentication via options in sources.list or files in /etc/apt/auth.conf and /etc/apt/auth.conf.d
Add an authentication mechanism for type: apt entries in package-repositories that takes an auth.conf.d formatted file
Why it needs to get done
Snapcraft doesn't restrict a workaround where you can put the authentication details into the URI like https://<user>:<pass>@example.com/repo however it does embed the secret into the build log, and some services like JFrog generate large keys which will lead to a "File name too long" error.
When embedding the secret into the URI, the build log might look something like this:
Further, without an authentication file, developers have to resort to workarounds like sed 's/{{AUTH}}/$PASS/' snap/local/snapcraft.yaml.in > snap/snapcraft.yaml in order to maintain different authentication sets between local developers and build servers.
What needs to get done
Apt repositories support authentication via options in sources.list or files in /etc/apt/auth.conf and /etc/apt/auth.conf.d
Add an authentication mechanism for
type: aptentries in package-repositories that takes an auth.conf.d formatted fileWhy it needs to get done
Snapcraft doesn't restrict a workaround where you can put the authentication details into the URI like
https://<user>:<pass>@example.com/repohowever it does embed the secret into the build log, and some services like JFrog generate large keys which will lead to a "File name too long" error.When embedding the secret into the URI, the build log might look something like this:
Further, without an authentication file, developers have to resort to workarounds like
sed 's/{{AUTH}}/$PASS/' snap/local/snapcraft.yaml.in > snap/snapcraft.yamlin order to maintain different authentication sets between local developers and build servers.