Quack,

I am using apt-cacher-ng and in order to use https I'm using the method
recommended by its author by prepending HTTPS/// to the host, which
gives URLs of the like:
http://HTTPS///myrepo.example.com/debian

Previously I was using o= to match but now prefers matching with the
origin. I realized that when using a proxy with this trick, and even if
I encode the slashes as %2f it is not matching. In fact after looking
into the code I found out it simply split at the first slash, and
matches with "HTTPS" which means it de facto matches all my configured
sources, not very practical.

I did not find any way to work around this problem. Would it be possible
to split using the non-decoded string maybe? (and we could ask the
apt-cacher-ng to recommend the encoded version instead) Or any other
solution?

Regards.
\_o<

Control: retitle -1 support origin pins based on path

This is correct, the hostname ends with the first /. Encoded characters
are not allowed inside hostnames I believe. Here the hostname is HTTPS
and the path is ///myrepo.example.com/debian.

So effectively, what you are asking for is to allow origin to pin based
on the path, not just the hostname, like we allow for apt_auth.conf.

It's possible to do this in 2.x since we have an extensible cache API
with private pointers where we could store an extended origin, without
breaking existing uses of origin.

Arguably we could also hack up a solution for acng's hack, but that
feels like the wrong approach.

Quack,

Sorry for the lag.

I need to way to securely restrict sources, so that a custom source for
a handful of packages is not going to touch anything else on my system.
 From a security point of view that's not sufficient of course but I
would like to avoid a project adding a custom build of some lib to
workaround a problem or other such situation.
Since o= is taken from the repo metadata it's clearly not a good fit, so
I tried with the origin, and if I do not use acng that's working fine.

Unless you could suggest anything else with the current features it
would be nice to add path support. It could totally be another keyword,
I can adapt to the syntax you prefer.

:-)

I'm not sure how other caches handle the HTTPS case but yes clearly
there's no reason to add dirty hacks.

Regards.
\_o<