On Wed, 15 Apr 2020 07:49:28 -0400
Greg Wooledge wrote:
> On Tue, Apr 14, 2020 at 07:12:47PM -0400, Lee wrote:
> > On 4/14/20, Greg Wooledge wrote:
> > > Accessing the mirrors via https makes the packages un-cacheable, which
> > > makes the traffic volume significantly greater -- and the package
On Wed 15 Apr 2020 at 07:49:28 (-0400), Greg Wooledge wrote:
> On Tue, Apr 14, 2020 at 07:12:47PM -0400, Lee wrote:
> > On 4/14/20, Greg Wooledge wrote:
> > > Accessing the mirrors via https makes the packages un-cacheable, which
> > > makes the traffic volume significantly greater -- and the pack
On Tue, Apr 14, 2020 at 07:12:47PM -0400, Lee wrote:
> On 4/14/20, Greg Wooledge wrote:
> > Accessing the mirrors via https makes the packages un-cacheable, which
> > makes the traffic volume significantly greater -- and the package lists
> > are already signed, so there's no gain in trustworthine
Hi.
On Tue, Apr 14, 2020 at 10:26:09PM +0100, Liam O'Toole wrote:
> On Tue, 14 Apr, 2020 at 23:42:48 +0300, Reco wrote:
>
> [...]
>
> > > 2. Having completed a DNS lookup unbeknownst to the ISP, we still have
> > > to make a connection to the resulting IP address through the ISP's
> > >
On Tue, 14 Apr, 2020 at 18:00:41 -0500, John Hasler wrote:
> Liam writes:
> > I think you misunderstand me. I'm talking about making a connection to
> > an IP address that you have already obtained by (encrypted) DNS. For
> > example, your personal bind instance tells you that www.debian.org
> > re
On 4/14/20, Greg Wooledge wrote:
> On Mon, Apr 13, 2020 at 07:03:12PM -0400, Lee wrote:
>> dnssec just adds a cryptographic signature to the data -- everything
>> is still done "in the clear" (like Debian updates. or has buster
>> switched to using https for downloading updates?)
>
> The apt-tran
Liam writes:
> I think you misunderstand me. I'm talking about making a connection to
> an IP address that you have already obtained by (encrypted) DNS. For
> example, your personal bind instance tells you that www.debian.org
> resolves to 130.89.148.77. Assuming you then connect to that IP
> addre
On Tue, 14 Apr 2020 22:26:09 +0100
Liam O'Toole wrote:
> On Tue, 14 Apr, 2020 at 23:42:48 +0300, Reco wrote:
>
> [...]
>
> > > 2. Having completed a DNS lookup unbeknownst to the ISP, we still have
> > > to make a connection to the resulting IP address through the ISP's
> > > gateway. The ISP c
On Tue, 14 Apr 2020 12:13:11 -0500
John Hasler wrote:
> Celejar writes:
> > why would they be limited by whatever the OS supports? Surely their
> > malware can easily include an internal DoH implementation,
>
> They needn't use DNS at all. Hard coded IPs work fin
On Tue, 14 Apr, 2020 at 23:42:48 +0300, Reco wrote:
[...]
> > 2. Having completed a DNS lookup unbeknownst to the ISP, we still have
> > to make a connection to the resulting IP address through the ISP's
> > gateway. The ISP can perform a reverse DNS lookup of the IP address if
> > they are deter
Hi.
On Tue, Apr 14, 2020 at 06:25:24PM +0100, Liam O'Toole wrote:
> I have two reservations about the approach advocated by Reco above.
> Maybe I'm not seeing some part of the big picture.
>
> 1. The risk of DNS snooping is merely shifted from the ISP to the VPS
> provider.
Usually you
On Mon, 13 Apr 2020 at 16:37, John Hasler wrote:
>
> Liam writes:
> > I'm not familiar with bind. Does it work by consulting root name
> > servers directly?
>
> It starts with the root servers and builds a database in exactly the
> same way your ISP's DNS server does. In fact, it is probably what
Celejar writes:
> why would they be limited by whatever the OS supports? Surely their
> malware can easily include an internal DoH implementation,
They needn't use DNS at all. Hard coded IPs work fine for reaching
their own servers. They are also not limited to the usual ports an
; >> > I just did a quick search and couldn't find anything for smart TVs
> >> > using DOH.
> >>
> >> Probably because they aren't there yet. A typical smart TV is based on
> >> the Android, and Google haven't said their word about DOH
Lee wrote:
> Maybe I'm being naive, but I'm taking the clause "except as may be
> required by law" to mean they can't just give the data to LE; there
> has to be some kind of court order compelling them to hand it over.
Reco writes:
> Probably. But I fail to see how a court order will prevent such
On Ma, 14 apr 20, 07:32:58, Greg Wooledge wrote:
> On Mon, Apr 13, 2020 at 07:03:12PM -0400, Lee wrote:
> > dnssec just adds a cryptographic signature to the data -- everything
> > is still done "in the clear" (like Debian updates. or has buster
> > switched to using https for downloading updates?
On Tue, Apr 14, 2020 at 07:06:05AM -0400, Lee wrote:
> >> Right. The ISP can't see what names the user is looking up but
> >> Cloudflare sees every single one. On the other hand, take a look at
> >> https://wiki.mozilla.org/Security/DOH-resolver-policy
> &g
ear - I'm not saying you should trust CloudFlare. It's just
> > that I don't see a whole lot of options & quite possibly CloudFlare is
> > more trustworthy than your USA ISP.
>
> Some non-profit organisations here operate public non-logging[1] DNS servers.
&g
x27;t see a whole lot of options & quite possibly CloudFlare is
> more trustworthy than your USA ISP.
Some non-profit organisations here operate public non-logging[1] DNS servers.
They all support DoT, only some support DoH.
But none of them would have enough resources to serve all Firefox u
On Mon, Apr 13, 2020 at 07:03:12PM -0400, Lee wrote:
> dnssec just adds a cryptographic signature to the data -- everything
> is still done "in the clear" (like Debian updates. or has buster
> switched to using https for downloading updates?)
The apt-transport-https package is available, but is n
On 4/14/20, Reco wrote:
> Hi.
Hi
> On Mon, Apr 13, 2020 at 06:42:10PM -0400, Lee wrote:
>> On 4/13/20, Reco wrote:
>> > On Sun, Apr 12, 2020 at 07:46:38PM -0400, Lee wrote:
>> >> > The questionable idea behind DOH is that the browser makers do not
>&
On 4/13/20, Celejar wrote:
> On Mon, 13 Apr 2020 08:47:22 +0300
> Reco wrote:
>
>> Hi.
>>
>> On Sun, Apr 12, 2020 at 07:46:38PM -0400, Lee wrote:
>
> ...
>
>> > I just did a quick search and couldn't find anything for smart TVs
>> >
On Mon, Apr 13, 2020 at 07:03:12PM -0400, Lee wrote:
> On 4/13/20, tomas wrote:
> > On Sun, Apr 12, 2020 at 07:46:38PM -0400, Lee wrote:
[...]
> Agreed. But how many home users have a local sys admin? That knows
> how to configure the local resolver?
>
> OK .. on this list, probably most. But
Hi.
On Mon, Apr 13, 2020 at 06:42:10PM -0400, Lee wrote:
> On 4/13/20, Reco wrote:
> > On Sun, Apr 12, 2020 at 07:46:38PM -0400, Lee wrote:
> >> > The questionable idea behind DOH is that the browser makers do not
> >> > trust
> >> > your lo
On Mon, 13 Apr 2020 08:47:22 +0300
Reco wrote:
> Hi.
>
> On Sun, Apr 12, 2020 at 07:46:38PM -0400, Lee wrote:
...
> > I just did a quick search and couldn't find anything for smart TVs
> > using DOH.
>
> Probably because they aren't there yet.
riggin' application*.
I prefer apps that don't "phone home".
> It'd be OK for the local DNS caching resolver to forward its
> queries to some DOH responder "out there", *configurable by
> the local sys admin. Locally, you have the same posibilities
>
On 4/13/20, Reco wrote:
> Hi.
Hi
> On Sun, Apr 12, 2020 at 07:46:38PM -0400, Lee wrote:
>> > The questionable idea behind DOH is that the browser makers do not
>> > trust
>> > your local resolver.
>>
>> Mozilla claims it's a privacy issu
Liam writes:
> I'm not familiar with bind. Does it work by consulting root name
> servers directly?
It starts with the root servers and builds a database in exactly the
same way your ISP's DNS server does. In fact, it is probably what your
ISP uses.
--
John Hasler
jhas...@newsguy.com
Elmwood,
Andrei writes:
> Whether DoH or DNS-over-TLS, you have to trust the DNS server.
You have to trust the root zone but you needn't trust any single server
other than your own with every single query.
--
John Hasler
jhas...@newsguy.com
Elmwood, WI USA
tomás writes:
> But letting an app bypass that, to some Mozilla-blessed DOH service is
> *not nice*.
I assume that Mozilla is only considering Windows users who are going to
use whatever DNS their ISP configured into their router.
--
John Hasler
jhas...@newsguy.com
Elmwood, WI USA
rote:
> >
> > [...]
> >
> > > > Whether DoH or DNS-over-TLS, you have to trust the DNS server.
> > >
> > > Yup. That's why I have my own, and every Debian user can have their own
> > > too, using only free software.
> > >
>
On Mon, Apr 13, 2020 at 12:14:44PM +0100, Liam O'Toole wrote:
> On Mon, 13 Apr, 2020 at 12:57:54 +0300, Reco wrote:
> > Hi.
> >
> > On Mon, Apr 13, 2020 at 11:16:02AM +0300, Andrei POPESCU wrote:
>
> [...]
>
> > > Whether DoH or DNS-over-TLS, yo
On Mon, 13 Apr, 2020 at 12:57:54 +0300, Reco wrote:
> Hi.
>
> On Mon, Apr 13, 2020 at 11:16:02AM +0300, Andrei POPESCU wrote:
[...]
> > Whether DoH or DNS-over-TLS, you have to trust the DNS server.
>
> Yup. That's why I have my own, and every Debian user can h
On Mon, Apr 13, 2020 at 12:57:54PM +0300, Reco wrote:
> Hi.
>
> On Mon, Apr 13, 2020 at 11:16:02AM +0300, Andrei POPESCU wrote:
[...]
> Yup. That's why I have my own, and every Debian user can have their own
> too, using only free software.
...and that is why I want the apps on my box to
es, DNSSEC is for integrity of zones, not privacy.
> > You need DNS-over-TLS if you need last one.
> >
> >
> > > At least Cloudflare resolvers have dnssec enabled.
> >
> > *And* the ability to see users' DNS queries. Neat, right?
>
> Whether DoH
e.
>
>
> > At least Cloudflare resolvers have dnssec enabled.
>
> *And* the ability to see users' DNS queries. Neat, right?
Whether DoH or DNS-over-TLS, you have to trust the DNS server.
Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
signature.asc
Description: PGP signature
hing resolver to forward its
queries to some DOH responder "out there", *configurable by
the local sys admin. Locally, you have the same posibilities
(resolv.conf, nsswitch, hosts).
But letting an app bypass that, to some Mozilla-blessed DOH
service is *not nice*.
Just imagine your soli
Hi.
On Sun, Apr 12, 2020 at 07:46:38PM -0400, Lee wrote:
> > The questionable idea behind DOH is that the browser makers do not trust
> > your local resolver.
>
> Mozilla claims it's a privacy issue:
> https://support.mozilla.org/en-US/kb/firefox-dns-over-h
for the pointer
>> anyway.
>>
>> Cheers
>> [1] That's not a rhethorical flourish, it's genuine. I know too
>>little about DNS-over-HTTP to be of any use at this point.
>
> The questionable idea behind DOH is that the browser makers do not trust
&
d into a
> > plain dns lookup.
>
> No, that's not how it works. When the browser wants to resolve a
> name, it doesn't "do" DNS (when it's doing DOH, that is) but uses
> some "web-service-ish" protocol over https to some server out there
> (
w it works. When the browser wants to resolve a
name, it doesn't "do" DNS (when it's doing DOH, that is) but uses
some "web-service-ish" protocol over https to some server out there
(cloudflare, e.g.) which does the resolution and answers via https.
Thus bypassing wha
; >
>
> Technically, that doesn't disable it, just just disables any 'on by
> default' DoH [1]. For individual users worried about this, it would be
> simpler not to accept it when Firefox asks to enable it, or to disable
> it it with a config option. [2] T
wants to resolve a
name, it doesn't "do" DNS (when it's doing DOH, that is) but uses
some "web-service-ish" protocol over https to some server out there
(cloudflare, e.g.) which does the resolution and answers via https.
Thus bypassing whatever scheme the sysadmin has se
t; The questionable idea behind DOH is that the browser makers do not trust
> your local resolver. As usual, main arguments here are:
[...]
Ah, OK. Thanks. Sounds a bit... fragile.
Now I know a bit more!
Cheers
-- t
signature.asc
Description: Digital signature
guration will disable this
> problematic feature for good for Firefox (basically it creates a
> bogus
> NXDOMAIN response for this particular site):
>
> local=/use-application-dns.net/
>
Technically, that doesn't disable it, just just disables any 'on by
default' DoH [1]. F
On Sunday 12 April 2020 06:35:44 to...@tuxteam.de wrote:
> On Sun, Apr 12, 2020 at 01:21:08PM +0300, Reco wrote:
> > On Sun, Apr 12, 2020 at 12:10:45PM +0200, to...@tuxteam.de wrote:
> > > That's why I cringe at the idea that browsers want to start doing
> > > name resolution over HTTPS.
> >
> > T
cal flourish, it's genuine. I know too
>little about DNS-over-HTTP to be of any use at this point.
The questionable idea behind DOH is that the browser makers do not trust
your local resolver. As usual, main arguments here are:
1) One can use a local resolver with the ability *not* t
On Sun, Apr 12, 2020 at 01:21:08PM +0300, Reco wrote:
> On Sun, Apr 12, 2020 at 12:10:45PM +0200, to...@tuxteam.de wrote:
> > That's why I cringe at the idea that browsers want to start doing
> > name resolution over HTTPS.
>
> This simple one line of dnsmasq configuration will disable this
> prob
On Sun, Apr 12, 2020 at 12:10:45PM +0200, to...@tuxteam.de wrote:
> That's why I cringe at the idea that browsers want to start doing
> name resolution over HTTPS.
This simple one line of dnsmasq configuration will disable this
problematic feature for good for Firefox (basically it creates a bogus
On Friday 23 September 2011 00:01:49 Bob Proulx wrote:
> Since you seem to have disk space now you should take a quick moment
> and install xdu.
Have already done so following your earlier advice - immediately I had a
functioning machine!
Thanks again,
Lisi
--
To UNSUBSCRIBE, email to debian-
Lisi wrote:
> Bob Proulx wrote:
> > After you clean up your disk space I would install xdu as a package.
> > Then clean up your ~/bin/xdu version as a final step since you won't
> > need it anymore.
>
> Thank you, Bob, for going to so much trouble to help me. As I keep saying -
> possibly to the
On Tuesday 20 September 2011 22:00:24 Bob Proulx wrote:
> Lisi wrote:
> > Have just realised that I can't do this yet because I haven't yet solved
> > the problem of installing it!!
>
> I am not sure how important this particular program is but I think it
> will help.
>
> Since it is really just a
On 9/20/2011 4:00 PM, Bob Proulx wrote:
Lisi wrote:
Have just realised that I can't do this yet because I haven't yet solved the
problem of installing it!!
I am not sure how important this particular program is but I think it
will help.
Following this tangent is taking Lisi further away fr
Lisi wrote:
> Have just realised that I can't do this yet because I haven't yet solved the
> problem of installing it!!
I am not sure how important this particular program is but I think it
will help.
Since it is really just a single binary program you can go through and
grab a copy of it manual
On Tuesday 20 September 2011 21:38:41 Lisi wrote:
> Thanks, Bob. I am about to try this - but before pressing enter and
> putting my box out of commission for the night as a result, I wanted to
> thank you for yet another constructive reply from this amazing list. :-)
Have just realised that I ca
On Wed, May 09, 2007 at 12:13:08AM +0200, pizzapie_linuxanchovies wrote:
>
> DOH!!--I meant to ask this: Anyone who can do a make-kpkg under a non-root
> account--what permissions do you see when you say ls -l
> /usr/bin/[b]dpkg[/b]?
>
Are you using fakeroot? That is the rec
DOH!!--I meant to ask this: Anyone who can do a make-kpkg under a non-root
account--what permissions do you see when you say ls -l /usr/bin/[b]dpkg[/b]?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
..'zless /usr/share/doc/rsync/sample-rsyncd.conf.gz '
...and the classic "nogroup".
--
..med vennlig hilsen = with Kind Regards from Arnt... ;-)
...with a number of polar bear hunters in his ancestry...
Scenarios always come in sets of three:
best case, worst case, and just in case.
--
To
On Thu, 8 Apr 1999, Andreas Persenius wrote:
> Actually, the ljet4m-filter _does_ assume that your printer handles
> Postscript. Use the ljet4-filter instead to get 600 DPI and Postscript
> conversion.
>
Aha! Yeah, that certainly fixes things. If only I knew my LaserJet
models better ;-) Thank
Firstly, do you know what netscape uses to print. Eg, when I press
print in NS, the dialogue box says:
Print Command: lpr
Also, what are you using to filter? I use magicfilter, 'cos it does
everything for you. If you use this, make sure you have run
magicfilterconfig
and this sets up a go
Well, since apt-get has been very zealous with its interdependency
upgrades, I seem to have hosed my printer configuration somewhere along
the way. See, when I try to print a page using Netscape, it dumps
postscript at my printer. Nasty! I don't think the problem is in my
printcap, unless the lj
On Wed, 30 Dec 1998, John Reid wrote:
> Also I may need to add hdc=cdrom as a boot parameter for my cdrom (see
> below) - I can't find anywhere obvious to do this in the install
> script. I tried adding the cdrom module and feeding it hdc=cdrom as a
> parameter - received error - this module
AIL PROTECTED]
> Message-Id: <[EMAIL PROTECTED]>
> Date: Tue, 29 Dec 1998 16:50:49 +0100 (CET)
> From: [EMAIL PROTECTED]
> Reply-To: [EMAIL PROTECTED]
> Subject: Re: Install wierdness or newbie goes doh!
> To: [EMAIL PROTECTED]
> cc: debian-user@lists.debian.org
> In-Repl
On 30 Dec, John Reid wrote:
> - 2Gb mode-4 ide disk drive on hda (3 partitions - 1.2gb fat32, ~515mb
> linux, 96mb linux swap)
I think this might be the problem. LILO has problems booting linux if
the primary linux partition is located above a certain block.
I think it would be best to have the l
Desperately seeking help!
Think I'm doing something silly in my installation. Is it necessary to
load/configure any modules for an integrated pci controller for ide
disk/cdrom (or for anything else - fairly plain vanilla system) using
the hamm cd's? If so, which ones? The install script doesn't s
On Fri, Apr 25, 1997 at 02:14:27PM -0400, Rick Jones wrote:
> Errr...I don't trust LBA. I ran LBA for several months and began to see a
> little corruption in my file system which began to propigate. Even though
> e2fsck came up clean programs began reporting missing files but an ls -al
> would s
Errr...I don't trust LBA. I ran LBA for several months and began to see a
little corruption in my file system which began to propigate. Even though
e2fsck came up clean programs began reporting missing files but an ls -al
would show the file in the right place. I don't know if it was LBA that
ca
On Thu, Apr 24, 1997 at 02:44:08PM -0400, Rick Jones wrote:
> I moved all my files from hda1 to hda2 with the kernel being the last file
> moved. So ofcourse it is beyond the 1023 line. That would explain it. My
> mind is going and I'm only 32.
Errr, so what? My root partition starts after an 80
>
> I moved all my files from hda1 to hda2 with the kernel being the last file
> moved. So ofcourse it is beyond the 1023 line. That would explain it. My
> mind is going and I'm only 32.
>
> Since I'm going to repartition this again I should give in and split it
> across partitions. You have a
Rick Jones writes:
> > New BIOS may support cylinders higher than 1023, but old BIOS doesn't.
> > Lilo may not make a distinction. I think you should check again what
> > cylinder hda2 starts on. The important fact is where the disk blocks for
> > your *kernel* are. With a large disk people oft
I moved all my files from hda1 to hda2 with the kernel being the last file
moved. So ofcourse it is beyond the 1023 line. That would explain it. My
mind is going and I'm only 32.
Since I'm going to repartition this again I should give in and split it
across partitions. You have a good layout fo
> Next try:
> URL I POSTed:
>
> http://www.hanoi.com/cgi-bin/joe/PFind.cgi?searchString=ncftp&default=frozen&searchAll=frozen%2Cunstable%2Ccontrib%2Cnon-free
^
Err what happened to hanoi.earthlight.co.nz??
I think what is happening is that the script posts the information to
> > The requested URL /cgi-bin/joe/PFind.cgi was not found on this server.
>
> A number of people have reported getting this error... if you are still
> getting it please let me know. It works perfectly for me so if it's
still
> broken i need to know so I can figure out why.
Uh, I don't get a sc
On Sat, 19 Apr 1997, Adam Shand wrote:
> > The requested URL /cgi-bin/joe/PFind.cgi was not found on this server.
>
> A number of people have reported getting this error... if you are still
> getting it please let me know. It works perfectly for me so if it's still
> broken i need to know so I c
> The requested URL /cgi-bin/joe/PFind.cgi was not found on this server.
A number of people have reported getting this error... if you are still
getting it please let me know. It works perfectly for me so if it's still
broken i need to know so I can figure out why.
Adam.
--
TO UNSUBSCRIBE FR
Ima dick...
The URL is: http://hanoi.earthlight.co.nz/cgi-bin/joe/PFind.cgi
Adam
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
76 matches
Mail list logo
