On Tue, Mar 15, 2016 at 11:27:26AM -0300, Tiago Ilieve wrote: > On 15 March 2016 at 01:46, Adam Bolte <abolte@systemsaviour.com> > wrote: > > I already pointed out a workaround for that. I use an apt-cache-ng > > server on my home LAN which improves both privacy and > > efficiency. Other people/companies run a local mirror for even > > better privacy and to avoid issues when remote networks or servers > > are unavailable. There are easy ways to address your concern which > > don't introduce problems. > > Your use case isn't everyone's use case. For instance, using > apt-cacher on my laptop wouldn't help me in any way, because nearly > every package download would be a new transfer being done in the > clear. I would probably be better served by apt-transport-tor in > this case, as you suggests later, but apt-transport-https would be > easier to use and fulfills my necessity. Are you quite sure? In some situations that involve only a single machine, it's possible the size alone of what you are downloading from your repository is enough to give the content away. Tor would at least completely hide the fact that you are even downloading a package update. In my opinion, if privacy is the primary concern, go all the way and use Tor. > I had so many problems with Ubuntu's "mirror.txt" that I prefer to > not talk about it. Can we focus on what Debian offers? > httpredir.debian.org is (IMHO) a much better service. I'll get into > it later in this message. It really doesn't matter. I just used that as a quick way to obtain a list of mirrors in my region. > I guess that no one talked about third-party repos in this > discussion. Just covering all bases. > This is exactly what Charles is asking: what do we think about this? > Would this be a shot in the foot? Of course I would like to more > mirrors to adopt HTTPS, but this shouldn't be imposed by the way > newer distributions handles connections the those servers. > > Actually, maybe I'm wrong, but AFAICT, apt-transport-https *enables* > the support for HTTPS mirrors, it *doesn't forces* every one of them > to use encrypted/authenticated connections. It allows https to be used in your sources.list-type files. It certainly doesn't revoke any other functionality you would normally have. > Then we have the problem of how we can use httpredir.debian.org this > way, but that's another issue (which may already been solved, but > I'm not aware of). If the package apt-transport-https was pre-installed, and all supported proxy programs such as apt-cacher, apt-cacher-ng, etc. also supported HTTPS (and I'm not sure that they do), httpredir should perhaps be able to return https URLs. Then it's just a matter of how you make that leap. Would most people be happy to use HTTP when HTTPS is available? Would https mirrors be happy with a potentially massive increase in traffic as a result of people switching to the one deemed more secure? Would Debian be happy to trust that mirrors keep their certificates managed correctly to avoid package update errors? etc. It's a lot to discuss, and (as I think someone mentioned earlier) I don't think this is really the correct list for it. > > I'm all for privacy, but I don't think the argument for inclusion > > of the package has been very well thought out. I think the > > inclusion of apt-transport-tor makes much more sense given your > > stated concern. > > Like I said in the beginning of this message, Tor is not as easy to > use as (and one can argue that it is not a substitute to) > HTTPS. Then, it doesn't makes sense to include it by default. Well that's one opinion, upon which your conclusion is based. :) In my opinion, I don't expect every single mirror would ever switch to HTTPS, or if they did, would always use certificates that are properly managed and trusted by the OS. I'd rather have the OS configure Tor out of the box, and have a more reliable situation for updates along with much better privacy - if privacy is the focus. In practise, since I use a proxy anyway which gives me a level of privacy I'm comfortable with, I would probably prefer plain HTTP - at least until the above concerns have been discussed and a plan is in place.
Attachment:
signature.asc
Description: Digital signature