apt-secure ignoring allow-unauthenticated during apt-update

[dundir]

It appears apt-get update is completely ignoring the allow-unauthenticated switch. This initially provided a significant roadblock to getting the system to recognize a trusted local repository as most literature and posts refer to use of this switch. I was able to discover a workaround though the time invested was steep. The [trusted=yes] option in sources.list(5) functions correctly and will bypass this authentication check. It would be helpful at a minimum if the apt --allow-unauthenticated description in the apt-get documentation referred to sources.list(5) option trusted=yes with an example if this switch is being deprecated.

Steps for Reproduction.

Bootup 16.10 LiveCD

Add to APT Sources
deb file:/tmp/local/ ./

Run the command, "apt-get --allow-unauthenticated update"

Output as follows with no internet connection:

https://pastebin.com/6h8tiHbN

*Initial apt-get --allow-unauthenticated update failed due to missing release file.
Generated generic release file to obtain the above output.

"apt install" for packages included cannot find desired package.

Local repo was set up via these instructions:
http://askubuntu.com/questions/170348/how-to-create-a-local-apt-repository

Packages.gz was generated using the below command.
dpkg-scanpackages ./ | gzip -9c > Packages.gz

[David Kalnischkies (donkult)]

Have you read apt-secure(8) manpage as the explanatory notice (N:) attached to the *warning* message says?

It explains why you see the *warnings*, that it is the propose of the switch to downgrade the *errors* to a *warning* (so that worked as intended) and it mentions how to configure that in sources.list – also hinting at "trusted".

[dundir (dundir)]

Thanks for pointing that out, that would have saved some time If I'd seen that the description section wasn't a simple description of what the utility does.

I usually skip directly past the man page description section as in almost every case I've come across it is a simple description of what the utility is or does.

I still believe this is a valid bug insofar as the apt-get --allow-unauthenticated does not function as described.

Additionally, the manpage for apt-secure and apt-get are at odds (inconsistent). The apt-secure page indicates the default behaviour of not downloading packages that are unsigned may be overridden explicitly for apt-get (--allow-unauthenticated is the only switch on the apt-get manpage which addresses this, and it doesn't work).

The apt-secure does provide for ways to allow insecure archives first and foremost (not optimal) and briefly mentions a Trusted option which did refer to sources as a way of removing warnings.

Maybe I'm missing something, its my understanding that warnings are an outputted warning and action continues, and errors actually stop a process.

The allow-unauthenticated did not downgrade all errors relating to signing to warnings. If it had, the apt-get update would have included the new packages and it would find the packages during an install command, but may not allow installation without explicit confirmation. The error resulting from the apt-get install command with the appropriate confirmation switch is a package not found error. Thus the --allow-unauthenticated is not downgrading signing related errors to warnings (which may along the line of though expressed in the description of apt-secure, or not, the documentation is unclear).

As a result of the above inconsistencies, standard troubleshooting practices would place a technically savvy user down a path that takes a significant amount of time, unnecessarily.

In addition to that, the inconsistencies also move the performance of a simple task of installing packages from a local resource into the realm of tacit knowledge as one must make the determination what's failing to work around the problem and anyone relying on the documentation will have to resolve several conflicts within the documentation before a solution can be found.

[David Kalnischkies (donkult)]

> The allow-unauthenticated did not downgrade all errors relating to signing to warnings.
> If it had, the apt-get update would have included the new packages and it would find
> the packages during an install command, but may not allow installation without explicit
> confirmation. The error resulting from the […]

It is actually the point of --allow-unauthenticated to skip the explicit confirmation for unauthenticated packages and nothing else since all of its existence… (because the 'complains' from "update" are new)

I was misreading "--allow-unauthenticated" for "--allow-insecure-repositories" – but for the record the documentation for the earlier one explicitly mentions the trusted option (at least in 1.4, not check earlier).