on countering stale mirrors this command may help? https://unix.stackexchange.com/a/45973
Context:
-o Acquire::Check-Valid-Until=falseIs a bad idea. It disables release file validation. Won’t counter stale mirrors. Will make them go unnoticed.
As per http://manpages.debian.org/cgi-bin/man.cgi?&query=apt.conf
Check-Valid-Until Security related option defaulting to true, as giving a Release file's validation an expiration date prevents replay attacks over a long timescale, and can also for example help users to identify mirrors that are no longer updated - but the feature depends on the correctness of the clock on the user system. Archive maintainers are encouraged to create Release files with the Valid-Until header, but if they don't or a stricter value is desired the Max-ValidTime option below can be used.
by using debian repos directly we are protected from a stale mirror attack, particularly security updates: https://unix.stackexchange.com/a/5009
As for randomzing link order hitting for apt update I haven’t found much. maybe we can compare order manually here by posting what we see.
Yes. Debian protects from it while Ubuntu does not (https://bugs.launchpad.net/launchpad/+bug/716535).
Don’t know what you mean.
Are times when "apt-get update" is run randomized to prevent a clear network fingerprint? If not, this needs a custom implementation/diverting some scripts.
I mean this. But how serious is it?
https://www.debian.org/doc/manuals/debian-faq/ch-uptodate.en.html
9.5 Can I automatically update the system?Yes. You can use cron-apt, this tool updates the system at regular interval by using a cron job. By default it just updates the package list and download new packages without installing.
Note: Automatic upgrade of packages is NOT recommended in testing or unstable systems as this might bring unexpected behaviour and remove packages without notice.
In theory automatic upgrades at non-randomized times could help an ISP level adversary to guess that you’re automatic upgrades over Tor. Therefore guess that you’re probably be a Whonix or custom transparent proxy rather than TBB user. No idea how serious that is. Probably something that is good to prevent, nice to have, but not as important as lots of other stuff.
Please update the list of research questions so I don’t look up things you have answers for. Adding references would let readers know an answer is found already.
Ideally you want to run cron at random times. This is possible: https://stackoverflow.com/questions/9049460/cron-jobs-and-random-times-within-giving-hours
There is nothing to update.
The point is “Are times when “apt-get dist-upgrade” is run randomized to prevent a clear network fingerprint? If not, this needs a custom implementation/diverting some scripts.”
Unattended upgrades that someone may want to implement as an [optional?] feature should check for that point.
That it should “run at randomized times to prevent a clear network fingerprint” is implicitly stated within the question.
It sure is possible.
All easy stuff. (In comparison: https://www.whonix.org/wiki/FAQ#How_difficult_is_it_to_develop_Whonix.3F)
One Debian unattended upgrades package is just a cron / shell script and adding a randomizing feature doable by any less than decent coder. What it needs are people who get the code done. Ideally merged into Debian. By suggesting a patch for Debian. As an option [so Whonix just turns this on] or even better turned on by default. I guess they’d like it randomized for other reasons (load balancing) anyway.
There is nothing to update.I meant this about the stale mirror fact. You seemed to have looked up before(?) I did for Debian. I'll add it to the documentation but I am not sure a dev page is the place to put it. Use as a FAQ.
The point is "Are times when "apt-get dist-upgrade" is run randomized to prevent a clear network fingerprint? If not, this needs a custom implementation/diverting some scripts."
Thanks for clarifying. I had the impression, you were looking for ways to make apt connect to the repo urls in a random order rather than having apt run at random times.
One Debian unattended upgrades package is just a cron / shell script and adding a randomizing feature doable by any less than decent coder. What it needs are people who get the code done. Ideally merged into Debian. By suggesting a patch for Debian. As an option [so Whonix just turns this on] or even better turned on by default. I guess they'd like it randomized for other reasons (load balancing) anyway.
I did not mean to imply that you do it. I thought it was something you wanted to implement in Whonix but needed more information/research on what you could use for it. Upstream makes sense, but the inertia of development makes such a request pointless almost.
I meant this about the stale mirror fact. You seemed to have looked up before(?) I did for Debian. I'll add it to the documentation but I am not sure a dev page is the place to put it. Use as a FAQ.The "debian notices stale mirror attack by using valid-until for release files" fact is a detail. Probably fine to add to a dev page.
What could be documented in documentation is the “Release file expired” message. Here:
What it means, what could cause it and how recommended action.
Thanks for clarifying. I had the impression, you were looking for ways to make apt connect to the repo urls in a random order rather than having apt run at random times.Ah. Okay.
Besides… Using random mirrors could make sense for load balancing. But that’s another discussion, no pressing issue yet and a fix not that simple.
[quote]One Debian unattended upgrades package is just a cron / shell script and adding a randomizing feature doable by any less than decent coder. What it needs are people who get the code done. Ideally merged into Debian. By suggesting a patch for Debian. As an option [so Whonix just turns this on] or even better turned on by default. I guess they'd like it randomized for other reasons (load balancing) anyway.[/quote]I did not mean to imply that you do it. I thought it was something you wanted to implement in Whonix but needed more information/research on what you could use for it.
Okay.
I see explaining this is quite difficult. That dev page is aiming to provide to answer for people suggesting:
- One click upgrade button for Debian packages
- Unattended upgrades in background for Debian packages
- Adding GUI Updater
All sounds quite simple at first thought, but really isn’t that simple.
For example…
Reasons against Automatic Updates: - Apparently mysterious [2] system load. - Apparently mysterious [2] network load.
Aren’t unsolvable issues.
With a good user interface it would be possible to have a notification in X as well as in terminal as well as having options to stop / postpone updates. But it’s not worth adding that information. To solve it we need creative people with a lot self initiative and motivation to develop it. Writing a full concept with full problem analysis and proposed solution while not having someone to implement it would be a lot wasted work that is better spend on actual development. Because I think to the ones who would have the creativity, self initiative and motivation to develop it, will occur such a simple thought on how to implement it anyway. The ones implementing such things are mostly also not the ones reading and implementing a full concept, I think. It’s less about information, it’s more about dialogue. Also a lot text that leaves no room for questions often rather scares potential contributors away. Having them propose the solution and then talking about implementation details is better timing.
Upstream makes sense, but the inertia of development makes such a request pointless almost.It depends on the maintainer. No matter how long it takes. Proposing the patch would be useful.