Subject: apt-cacher-ultra beta: Another apt cache, focusing on reliability and offline availability.

I've been working on a new apt cacher I'm calling "apt-cacher-ultra", with
two goals in mind:
-
Robustness.
-
Availability when upstream is down.
I consider it to be at the beta stage now, I'm slowing down development and
I'm mostly just letting it soak in my various environments to get hours on
it to see how robust it proves to be. https://github.com/linsomniac/apt-cacher-ultra
There are binary and deb packages available on the releases link there. It should be a strict superset of apt-cacher-ng, it supports the " http://HTTPS///" kludge, for example.
Features:
-
MITM https proxy so you don't need to do the "http://HTTPS///" kludge,
but you can also get the benefit of the cache (-ng does a binary
passthrough which bypasses the cache).
-
Repo "snapshotting" and hot package refresh so if the upstream is
offline/DDoSed, you can still do installs/updates of your typical package
set.
-
Admin UI and metrics.
I've got it running on my infrastructure, as a proxy for nearly 200 Ubuntu machines across 5 environments, and while young it has proven reliable. At
this point I want to run it for at least a month before I start looking at doing a 1.0 release. I have tested it while the upstream Internet was
blocked and it performed without interruption during a new machine install
and dist-upgrade.


--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: apt-cacher-ultra beta: Another apt cache, focusing on reliability and offline availability.

Hi,

On Tue, May 19, 2026 at 08:51:34AM -0600, Sean Reifschneider wrote:

I've been working on a new apt cacher I'm calling "apt-cacher-ultra", with two goals in mind:

-

Robustness.
-

Availability when upstream is down.

I consider it to be at the beta stage now, I'm slowing down development and I'm mostly just letting it soak in my various environments to get hours on
it to see how robust it proves to be.

https://github.com/linsomniac/apt-cacher-ultra

Very interesting, thanks, I shall take a look. I currently use
apt-cacher-ng and have done for a long time but it's been very
unreliable in recent releases. I have big problems with:

- Memory leaks. Every few days apt-cacher-ng process exceeds its RAM
allocation and invokes oom-killer.

- Strange client lockups. "apt update" on some clients occasionally hang
forever.

- Segfaults in apt-cacher-ng process

All these reported as bugs long ago by others so I've nothing to add to
those bug reports and no real hope of seeing a fix.

So all that to say: I welcome another project attempting to pull this
off: I'm in the market for a replacement and if it's a drop-in for apt-cacher-ng then that would be ideal.

Thanks,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: apt-cacher-ultra beta: Another apt cache, focusing on reliability and offline availability.

On Tue, 19 May 2026 08:51:34 -0600
Sean Reifschneider <jafo00@gmail.com> wrote:

I've been working on a new apt cacher I'm calling "apt-cacher-ultra",

Interesting. Please keep us posted.

MITM https proxy so you don't need to do the "http://HTTPS///"
kludge, but you can also get the benefit of the cache (-ng does a
binary passthrough which bypasses the cache).

I'm not familiar with this. Can you point me to a writeup on how to use
it and how to use the MITM proxy? I assume here that MITM is Man In The
Middle.

Thanks.

--
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: apt-cacher-ultra beta: Another apt cache, focusing on reliability and offline availability.

Well, I tried to find the .deb package, but in `many cases github is such a messy site. Sometimes a developer will have a clear download link, but much of the time its long toolbars-and-a bunch of non-links which just say "button" Thanks in advance
Chime

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: apt-cacher-ultra beta: Another apt cache, focusing on reliability and offline availability.


On 19/05/2026 19:05, Chime Hart wrote:

Well, I tried to find the .deb package, but in `many cases github is such a messy site. Sometimes a developer will have a clear download link, but much of
the time its long toolbars-and-a bunch of non-links which just say "button"

GItHub has (somewhat) embraced the idea of "Cool URIs". If you're
looking for the downloads for a repository, they'll be under https://github.com/<organisation>/<repository>/releases (similarly, if
you want bugs, they're under https://github.com/<organisation>/<repository>/issues and so on). In
theory, there's a predictable path to release assets, too, but they do
tend to require you to know what version you want, first.

Thanks in advance
Chime

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: apt-cacher-ultra beta: Another apt cache, focusing on reliability and offline availability.

Hi,

On Tue, May 19, 2026 at 03:17:34PM +0000, Andy Smith wrote:

On Tue, May 19, 2026 at 08:51:34AM -0600, Sean Reifschneider wrote:

https://github.com/linsomniac/apt-cacher-ultra

Very interesting, thanks, I shall take a look.

I've had 5 minutes worth of looking and I have to say the contribution
policy is giving me some concern. TL;DR: they ONLY accept AI-assisted contributions.

https://github.com/linsomniac/apt-cacher-ultra/blob/main/CONTRIBUTING.md

It's probably this or switching to a general HTTP proxy (e.g. Squid) so
I guess I'll still try it out, but?

Thanks,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: apt-cacher-ultra beta: Another apt cache, focusing on reliability and offline availability.

On Tue, May 19, 2026 at 06:40:31PM +0000, Andy Smith wrote:

Hi,

On Tue, May 19, 2026 at 03:17:34PM +0000, Andy Smith wrote:

On Tue, May 19, 2026 at 08:51:34AM -0600, Sean Reifschneider wrote:

https://github.com/linsomniac/apt-cacher-ultra

Very interesting, thanks, I shall take a look.

I've had 5 minutes worth of looking and I have to say the contribution
policy is giving me some concern. TL;DR: they ONLY accept AI-assisted contributions.

https://github.com/linsomniac/apt-cacher-ultra/blob/main/CONTRIBUTING.md

Huh?
I actually tried to wget that "markdown" and, yikes.
So, I'll pass, thanks. Thanks for the heads-up.
(Being on Github was already a turndown, but that would've been somewhat surmountable)
Cheers
--
t


--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: apt-cacher-ultra beta: Another apt cache, focusing on reliability and offline availability.

On 2026-05-19 at 14:54, tomas@tuxteam.de wrote:

On Tue, May 19, 2026 at 06:40:31PM +0000, Andy Smith wrote:

Hi,

On Tue, May 19, 2026 at 03:17:34PM +0000, Andy Smith wrote:

On Tue, May 19, 2026 at 08:51:34AM -0600, Sean Reifschneider wrote:

https://github.com/linsomniac/apt-cacher-ultra

Very interesting, thanks, I shall take a look.

I've had 5 minutes worth of looking and I have to say the contribution
policy is giving me some concern. TL;DR: they ONLY accept AI-assisted
contributions.

https://github.com/linsomniac/apt-cacher-ultra/blob/main/CONTRIBUTING.md

Huh?

I actually tried to wget that "markdown" and, yikes.

Try appending '?raw=true' to the URL. I was able to wget it in readable
form that way.

So, I'll pass, thanks. Thanks for the heads-up.

The "AI-only contribution policy" is a fairly alarming red flag,
certainly. The only way it could be reasonable is if this is an intentional-parody setup, and that doesn't look to be the case from what
I can see.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw


--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: apt-cacher-ultra beta: Another apt cache, focusing on reliability and offline availability.

On 2026-05-19 at 18:49, Sean Reifschneider wrote:

The only way it could be reasonable is if this is an
intentional-parody setup

I do cover it in the CONTRIBUTING document, I'll include that section
below. I'll add further color by saying that the idea came to me as,
in your words, an intentional parody, in the shower a few days ago.
But the more I thought about it the more I felt it was an important
social experiment to run. The phrase "somebody has to be first" came
to mind as well.

From the CONTRIBUTING.md:

<snip>
I read that, in the document after downloading it, yes.
I'll be blunt:
That clause not only leaves me disinclined to contribute to the project,
but disinclined to use it, and inclined to recommend *against* other
people using it. The explanations you give in that document do not help
with this, and some of them actually strengthen it.
Even if we leave aside all the other possible reasons (for one thing,
the other side's arguments having merit doesn't mean that reversing them
also has merit; for another, having the reversed setup be something
someone's actually trying helps give credit to "both-sides-ism"
arguments, even if that wasn't your intent), the aspect of "if you want
to express your disagreement with this principle and not have me ignore
you, you must follow this principle in how you express that
disagreement" or "if you don't accept our policy enough to at least use
it for talking to us, we will reject any attempt at talking to us you
make" is... mildly offensive to me, to put it mildly.
(I try not to focus very deeply or very long on such offenses nowadays,
because I know from experience that if I do so, I can and will devolve
into an apoplectic rage. And that's not helpful to *me*, much less to
anyone else.)
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw


--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: apt-cacher-ultra beta: Another apt cache, focusing on reliability and offline availability.

On Tue, May 19, 2026 at 4:54?PM Andy Smith <andy@strugglers.net> wr
ote:

On Tue, May 19, 2026 at 03:17:34PM +0000, Andy Smith wrote:

On Tue, May 19, 2026 at 08:51:34AM -0600, Sean Reifschneider wrote:

https://github.com/linsomniac/apt-cacher-ultra

Very interesting, thanks, I shall take a look.

I've had 5 minutes worth of looking and I have to say the contribution
policy is giving me some concern. TL;DR: they ONLY accept AI-assisted contributions.

https://github.com/linsomniac/apt-cacher-ultra/blob/main/CONTRIBUTING

.md

That policy ensures a lot of experienced folks will pass on reporting
bugs and submitting patches. Is it any wonder the program is having
stability problems?

It's probably this or switching to a general HTTP proxy (e.g. Squid) so
I guess I'll still try it out, but?

Jeff

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: apt-cacher-ultra beta: Another apt cache, focusing on reliability and offline availability.

On Tue, 19 May 2026 16:29:59 -0600
Sean Reifschneider <jafo00@gmail.com> wrote:

I'm not familiar with this. Can you point me to a writeup on how to
use it

In apt-cacher-ng (possibly originating from apt-cacher?), if you
request an https repo from the cache,?.

Thank you.

A third way to handle the problem is to tell apt et al. to bypass the
proxy for certain repos. For example, edit

Acquire::https::Proxy::updates.signal.org "DIRECT";

into (e.g.) /etc/apt/apt.conf.d/02signal-direct. That is OK for a small network, not so good for a large one.


--
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: apt-cacher-ultra beta: Another apt cache, focusing on reliability and offline availability.

On Tue, May 19, 2026 at 09:42:19PM -0600, Charles Curley wrote:

On Tue, 19 May 2026 16:29:59 -0600
Sean Reifschneider <jafo00@gmail.com> wrote:

I'm not familiar with this. Can you point me to a writeup on how to
use it

In apt-cacher-ng (possibly originating from apt-cacher?), if you
request an https repo from the cache,?.

Thank you.

Thank you for making reading in the discussion order possible.
And thanks for deleting lines from older messages in the thread.

A third way to handle the problem is to tell apt et al. to bypass the
proxy for certain repos. For example, edit

Acquire::https::Proxy::updates.signal.org "DIRECT";

into (e.g.) /etc/apt/apt.conf.d/02signal-direct. That is OK for a small network, not so good for a large one.

Nice advice, thanks again.

Does anybody read signatures any more?

I do ....


Groeten
Geert Stappers
--
Silence is hard to parse

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: apt-cacher-ultra beta: Another apt cache, focusing on reliability and offline availability.

On Tue, May 19, 2026 at 03:22:46PM -0400, The Wanderer wrote:

On 2026-05-19 at 14:54, tomas@tuxteam.de wrote:

[...]

I actually tried to wget that "markdown" and, yikes.

Try appending '?raw=true' to the URL. I was able to wget it in readable
form that way.

Thanks for the hint, as always insightful for you. I guessed that
was the "embellished" markdown, so I expected some fluff around;
I have some practice in squinting and rough-filtering the content
out of that kind of html-css-javascript soup ;-)
My "yikes" was thus at two levels, content and form (the javascript
code's hostility literally stares at you).
Cheers (and thanks for your other insights in this thread: I seem
to be pretty squarely in your camp, but lack your eloquence)
--
tom s


--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: apt-cacher-ultra beta: Another apt cache, focusing on reliability and offline availability.

On 2026-05-19 at 20:45, Sean Reifschneider wrote:

I doubt this addresses your concerns, but in reviewing the wording
in CONTRIBUTING.md to try to understand where you are coming from, I
made a few changes to clarify that by "comments" I meant "code
comments", and to further state that documentation and translations
are naturally likely to be a mix of human and AI work.

FWIW, while that does improve the picture *slightly*, my
communication-related comments were referring more to the "issues" part.
To the best of my awareness (which I will immediately admit may not be sufficient), the primary or even exclusive way GitHub provides for
someone to *initiate communication with* the maintainers of a project
hosted there is by opening an issue - and if you will reject (and
therefore, presumably, immediately or even automatically close, with no substantive response) any issue filed in a way that does not comply with
the policy outlined, that means that someone who does not find that
policy acceptable *has no way of talking to you*, whether to discuss
that fact or for any other reason, unless they can identify you and find
a way to contact you by some other means.
That sort of foreclosing of potential communication, and the associated ossification (through prevention of disagreeing viewpoints) of the "my
way or the highway" policy involved, is the thing that gets my blood so
heated about such matters.
Even addressing that would, as you suspect, indeed not change my overall
stance - because (as noted in my previous post) this is just the aspect
which gets the most heated emotional reaction from me, not by any means
the only one. I find no merit in the positions you appear to be taking
on this, or in the arguments you've presented for them, and I think that
the very fact of *anyone* attempting to take those positions in an
actual real-world software project - other than as parody, i.e., with
the intended goal be to show how nonsensical those same positions are -
helps fuel the ability of others to make illegitimate arguments in the
overall debate.
If that *is* your goal here, then you're doing if anything too good a
job of concealing it. It really does look as if you're trying to make
the positions taken by the "other side" look nonsensical instead, notwithstanding the explicit statement in CONTRIBUTING.md to the
contrary - and even if that is in fact not your intent, as I said, I
think the fact that anyone is standing where this project appears to
stand in that debate helps strengthen bad argument in the debate as a
whole.

I will admit I took a focused stance on the wording, expecting that
people would know that there will be exceptions and we can address
them as they arise.

That is, whether fortunately or unfortunately, not the default
expectation these days. While it may be the default *if no policy is
stated*, generally, if someone cares enough about something to express
it as a policy statement, if there is no statement about the possibility
of exception that is to be treated as a statement in itself.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw


--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: apt-cacher-ultra beta: Another apt cache, focusing on reliability and offline availability.

Hi,

On Tue, May 19, 2026 at 09:16:10PM -0400, Jeffrey Walton wrote:

On Tue, May 19, 2026 at 4:54?PM Andy Smith <andy@strugglers.net> wrote:

I've had 5 minutes worth of looking and I have to say the contribution policy is giving me some concern. TL;DR: they ONLY accept AI-assisted contributions.

https://github.com/linsomniac/apt-cacher-ultra/blob/main/CONTRIBUTING.md

That policy ensures a lot of experienced folks will pass on reporting
bugs and submitting patches. Is it any wonder the program is having stability problems?

If you're referring to problems I mentioned, note that those were about apt-cacher-ng, which is packaged in Debian. I've not yet had chance to
try apt-cacher-ultra which is what is being discussed here.

Thanks,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: apt-cacher-ultra beta: Another apt cache, focusing on reliability and offline availability.

On 2026-05-20, Jeffrey Walton <noloader@gmail.com> wrote:

I've had 5 minutes worth of looking and I have to say the contribution
policy is giving me some concern. TL;DR: they ONLY accept AI-assisted
contributions.

https://github.com/linsomniac/apt-cacher-ultra/blob/main/CONTRIBUTING.md

That policy ensures a lot of experienced folks will pass on reporting
bugs and submitting patches. Is it any wonder the program is having stability problems?

It's probably this or switching to a general HTTP proxy (e.g. Squid) so
I guess I'll still try it out, but?

I didn't look at the link and I'm not sure this is related, but I saw
that Linus had complained on the kernel mailing list that there were
multiple bug reports for the same vulnerability because people were
using AI and deriving the same results.

Jeff

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: apt-cacher-ultra beta: Another apt cache, focusing on reliability and offline availability.

On 2026-05-19, The Wanderer <wanderer@fastmail.fm> wrote:

The "AI-only contribution policy" is a fairly alarming red flag,
certainly. The only way it could be reasonable is if this is an intentional-parody setup, and that doesn't look to be the case from what
I can see.

Where do people in the know host their shit then?

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: On the reporting of security bugs discovered by LLM (Was Re: apt-cacher-ultra beta: Another apt cache, focusing on reliability and offline availability.)

Hi,

On Wed, May 20, 2026 at 03:55:00PM -0000, CGS wrote:

I saw that Linus had complained on the kernel mailing list that there
were multiple bug reports for the same vulnerability because people
were using AI and deriving the same results.

Some thoughts on that.

Everyone who has access to one of the commercial LLMs has the ability to
find those security bugs.

There's no way to un-invent the LLMs or restrict access to them.

I'd rather the security issues be reported multiple times than no times.

I'm pretty sure that Linus and most other kernel developers agree with that.

I think the rate of discoveries will slow down soon, only to increase
again shortly after each release of an improved LLM.

We need to worry about the time between private LLM advances and their
public release, because that's when people have access to lots of "zero
day" security bugs.

Thanks,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: apt-cacher-ultra beta: Another apt cache, focusing on reliability and offline availability.

On Tue, 19 May 2026 19:07:19 -0400
The Wanderer <wanderer@fastmail.fm> wrote:

I'll be blunt:

That clause not only leaves me disinclined to contribute to the
project, but disinclined to use it, and inclined to recommend
*against* other people using it. The explanations you give in that
document do not help with this, and some of them actually strengthen
it.

I concur.

I've been writing code for almost half a century. Some of it has
contributed to projects such as Jet Propulsion Lab's Cassini mission.
All of it without so much as a whiff of AI. I have yet to see any use
for AI. So this policy excludes me, quite possibly to the detriment of
the project.

This project already is what the policy describes. Every line of apt-cacher-ultra was written by an AI assistant working with a human director. Keeping the contribution model consistent with how the
project was built feels reasonable.

You could have a policy of contributions only from intelligent
entities. That would remove the artificial and unwarranted
discrimination against natural intelligence.

"Keeping the contribution model consistent with how the project was
built" does not lead me to the conclusion that you have to accept
contributions only from AI. I find it a complete non-sequitur.

--
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: apt-cacher-ultra beta: Another apt cache, focusing on reliability and offline availability.

On Wed, 20 May 2026 13:15:02 -0600
Sean Reifschneider <jafo00@gmail.com> wrote:

Sounds like we both got started coding around the same time. ;-)
I've been experimenting with the AI coding tools for around 3 years
now, and I have found a use for the tooling: In around 40 hours of
my attention I have something that manual coding would have
taken ~9 months of focused effort.

That is an interesting result. Which AI setup are you using and what
does it cost?

I do have a project which might be a good candidate for some AI
assistance. I have a program written to use GTK2, which will go away at
some point. An AI trained in the various versions of GTK might be
useful for bringing that up to the latest version of GTK.

This contributor arrangement is an experiment, and we'll see how
it goes. If it plays out that this project has suffered because of
the lack contributions by senior coders such as yourself, that is a
useful deliverable in my mind.

Fair enough. Carry on.

I appreciate your feedback on the wording, I'll ponder that because
my intention is to have this experiment be about AI generated
software, so I may want to select different wording.

Again, fair enough. Carry on.

--
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: apt-cacher-ultra beta: Another apt cache, focusing on reliability and offline availability.

On Wed, May 20, 2026 at 12:04?AM Andy Smith <andy@strugglers.net> w
rote:

Hi,

On Tue, May 19, 2026 at 03:17:34PM +0000, Andy Smith wrote:

On Tue, May 19, 2026 at 08:51:34AM -0600, Sean Reifschneider wrote:

https://github.com/linsomniac/apt-cacher-ultra

Very interesting, thanks, I shall take a look.

I've had 5 minutes worth of looking and I have to say the contribution
policy is giving me some concern. TL;DR: they ONLY accept AI-assisted contributions.

https://github.com/linsomniac/apt-cacher-ultra/blob/main/CONTRIBUTING

.md


Hey, at least they don't have that BS code-of-conduct that was so
popular by big corporations during peak-woke.

But it's funny how people who disagree with it are not allowed to
discuss the issue... because issues must be AI-generated. So yeah,
good try but no thanks. :)

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: apt-cacher-ultra beta: Another apt cache, focusing on reliability and offline availability.

Hello,

On Thu, May 21, 2026 at 12:11:48AM +0200, Anders Andersson wrote:

On Wed, May 20, 2026 at 12:04?AM Andy Smith <andy@strugglers.net> wrote:

I've had 5 minutes worth of looking and I have to say the contribution policy is giving me some concern. TL;DR: they ONLY accept AI-assisted contributions.

https://github.com/linsomniac/apt-cacher-ultra/blob/main/CONTRIBUTING.md

Hey, at least they don't have that BS code-of-conduct that was so
popular by big corporations during peak-woke.

The Debian project also has a code of conduct which also applies to this mailing list, and that code of conduct is pretty similar to what one
would find in a typical software repository. So I think your views on
codes of conduct are not only at odds with mine but also with those of
Debian at large.

The CONTRIBUTING.md in question does also have a "Code of Conduct"
section at the end which makes me wonder if you did even read that far.

Thanks,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: apt-cacher-ultra beta: Another apt cache, focusing on reliability and offline availability.

On Wed, 20 May 2026 15:10:37 -0600
Sean Reifschneider <jafo00@gmail.com> wrote:

As far as cost, my work pays $110/mo for the "Claude Pro 5x" plan,
and most months I pay another $100-ish on top of that to get the
"Pro 20x" upgrade ($200+tax).

Well, that's more than I want to pay. I don't have an employer to cover
that.

If that's software that you do or would share the code for, I'd be
happy to feed it to Claude to see what it can do, to give you an idea.

https://github.com/charlescurley/gnome-gps

"This program is released under the same terms as gpsd itself, i.e.
under the BSD License. See the file Copying in the gpsd distribution."

I'll be curious to see what you come up with. I haven't done any GUI programming since I completed that, 2010ish, so my background there is
rather rusty. But I'm pretty current on the GPS and gpsd side of things.

And this is wandering far afield. We should probably take this
discussion off the list.

--
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: apt-cacher-ultra beta: Another apt cache, focusing on reliability and offline availability.

On Thu, May 21, 2026 at 4:44?AM Andy Smith <andy@strugglers.net> wr
ote:

Hello,

On Thu, May 21, 2026 at 12:11:48AM +0200, Anders Andersson wrote:

On Wed, May 20, 2026 at 12:04?AM Andy Smith <andy@strugglers.ne

wrote:

I've had 5 minutes worth of looking and I have to say the contributio

n

policy is giving me some concern. TL;DR: they ONLY accept AI-assisted contributions.

https://github.com/linsomniac/apt-cacher-ultra/blob/main/CONTRIBU

TING.md

Hey, at least they don't have that BS code-of-conduct that was so
popular by big corporations during peak-woke.

The Debian project also has a code of conduct which also applies to this mailing list, and that code of conduct is pretty similar to what one
would find in a typical software repository. So I think your views on
codes of conduct are not only at odds with mine but also with those of
Debian at large.

The CONTRIBUTING.md in question does also have a "Code of Conduct"
section at the end which makes me wonder if you did even read that far.

I did. It's short and sweet. Compare for example with gnome, which has apparently grown enough to get its own subdomain!
(https://conduct.gnome.org/)

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: apt-cacher-ultra beta: Another apt cache, focusing on reliability and offline availability.

Sean Reifschneider <jafo00@gmail.com> writes:

I've been working on a new apt cacher I'm calling "apt-cacher-ultra", with two goals in mind:

With a quick look, it seems to work nicely. Then again, so does
apt-cacher-ng, it's just that later when you try to use it, it won't
respond or responds with error and needs a restart.

* MITM https proxy so you don't need to do the "http://HTTPS///" kludge, but you can also get the benefit of the cache
(-ng does a binary passthrough which bypasses the cache).

This feature might need some looking into or at least a little
documentation on how to use it, e.g. how to specify the regexp? The
example config in readme doesn't seem to work, as in the regexp isn't
accepted.

Even with something simple, like just debian.org in the regexp, I was
able to connect to deb.debian.org but not even to
security.debian.org. Let alone the repos I actually want to connect,
mega, nvidia, spideroak, spotify... Everything but deb.debian.org came
back with a certificate error. So, documentation, a working example, or explanation? Or maybe I did something wrong. And, to be honest, those non-Debian repos I use so little the caching doesn't much matter. But
how do you use apt-cacher-ultra for https without caching?

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: apt-cacher-ultra beta: Another apt cache, focusing on reliability and offline availability.

Even with something simple, like just debian.org in the regexp, I was
able to connect to deb.debian.org but not even to

Unlike -NG, -Ultra has a lot of knobs for hardening the cache, as you've
seen. I'm leaning towards the default being more permissive (like -NG), because the expected primary use case is inside a trusted network. Then
the knobs become available for hardening it in environments where that
is necessary, but the Quickstart becomes much easier.
I believe what you're running into is two things: The allowed regex and
the MITM Cert. The MITM cert also limits the names it will give out in
the default config. So allows need to be done in both places. **BUT**
the CA cert also needs to be regenerated after changing the MITM allow.
It does warn about this on start up, but you have to go look at the logs
to surface that. I'm going to change that so that it loudly complains
and aborts in that case.
I'm going to push some changes to the default config that open it up.
You should be able to get the new config, and then remove `/var/cache/apt-cacher-ultra/ca/*` and restart apt-cacher-ultra. It
should then generate a new CA, and you will need to copy that
ca.crt to the client machine to continue testing. At that point it
should work for you.
In my environment I started with things wide open and then looked at
the logs after a few days and used actual usage to create the allow
lists. However, I've since come to the mind that because of signing of
remote packages, the CA being limited to apt use only, and typical use
inside a trusted network that has public Internet access anyway, that
a more open default is probably better.
Sean
On Fri, May 22, 2026 at 12:55?PM Anssi Saari < anssi.saari@debian-user.mail.kapsi.fi> wrote:

Sean Reifschneider <jafo00@gmail.com> writes:

I've been working on a new apt cacher I'm calling "apt-cacher-ultra",

with two goals in mind:

With a quick look, it seems to work nicely. Then again, so does apt-cacher-ng, it's just that later when you try to use it, it won't
respond or responds with error and needs a restart.

* MITM https proxy so you don't need to do the "http://HTTPS///"

kludge, but you can also get the benefit of the cache

(-ng does a binary passthrough which bypasses the cache).

This feature might need some looking into or at least a little
documentation on how to use it, e.g. how to specify the regexp? The
example config in readme doesn't seem to work, as in the regexp isn't accepted.

Even with something simple, like just debian.org in the regexp, I was
able to connect to deb.debian.org but not even to
security.debian.org. Let alone the repos I actually want to connect,
mega, nvidia, spideroak, spotify... Everything but deb.debian.org came
back with a certificate error. So, documentation, a working example, or explanation? Or maybe I did something wrong. And, to be honest, those non-Debian repos I use so little the caching doesn't much matter. But
how do you use apt-cacher-ultra for https without caching?

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: apt-cacher-ultra beta: Another apt cache, focusing on reliability and offline availability.

Sean Reifschneider <jafo00@gmail.com> writes:

I'm going to push some changes to the default config that open it up.
You should be able to get the new config, and then remove `/var/cache/apt-cacher-ultra/ca/*` and restart apt-cacher-ultra. It
should then generate a new CA, and you will need to copy that
ca.crt to the client machine to continue testing. At that point it
should work for you.

OK, I've now tried again with 0.9.7. Initially I was in the same boat as before, only deb.debian.org could be accessed. I missed this advice or I
guess I assumed removing the package would remove
/var/cache/apt-cacher-ultra but it doesn't. Maybe something to consider
for the postrm script, it seems at least /var/cache/apt-cacher-ultra/ca
should be removed or cleaned.

So, after managing a clean install I got the default unrestriced mitm
config going, only changed the listen part in config.toml. And then the restricted mitm too. So for the machine running the cache at least, the
cache works. I'll continue with some further testing later.

But I'm still baffled as to when the cert needs regenerating? For
example, after initial trials with deb.debian.org and
security.debian.org I added mega.nz. The cert is still the same but
things seem to be working. At least no errors from apt update. Your
advice implies adding mega.nz should've needed a new certificate.

In my environment I started with things wide open and then looked at
the logs after a few days and used actual usage to create the allow
lists. However, I've since come to the mind that because of signing of remote packages, the CA being limited to apt use only, and typical use
inside a trusted network that has public Internet access anyway, that
a more open default is probably better.

Logging is another question, why does it look more like json in
journalctl than traditional logging? Oh, it's the default. But why json
by default? And also, not much point in putting a timestamp in the log
when systemd (or journald) already puts a timestamp in there.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: apt-cacher-ultra beta: Another apt cache, focusing on reliability and offline availability.

removing the package would remove /var/cache/apt-cacher-ultra but it

doesn't.
I think generally removing a package doesn't remove non-package files. I'm open to the idea that this is wrong though.

But I'm still baffled as to when the cert needs regenerating?

The cert it creates is a *CA* cert, which the MITM then uses to create and
sign
certs for things like deb.debian.org, mega.nz, etc. If you look in the
admin
interface under "TLS MITM", it'll say something like "CERT CACHE: 11 of
256",
those are the server certs that have been generated off the CA.
So, adding server names that you want to cache do not require generating
and distributing a new CA cert.

But why json by default?

It was a call I made, but I don't have a strong opinion on the default
there,
I'll push out a new release with a few small changes after I have a chance
to
test it in a bit, and that'll include the switch to text as the default log format
and the removal of the time (there is still a case for time in the JSON
format
since the timestamp exists outside of the JSON entry, but I've removed it
from both for the time being, and I can add it back in later if it seems useful.
Thanks for the feedback!
In my testing, it's still very on track for a mid June 1.0 release. I've
run
thousands of system installs and thousands of apt update/upgrade cycles
and the issues I've run into have been addressed, 0.9.7 has been working
great with no adoption failures (the biggest issue I'd been running into;
the
adoption is the trickiest part but also the most worthwhile WRT surviving DDoS).
Sean


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)