On Thu, 18 Jun 2015, Dan Williams wrote:
True. In fact with unbound it is pretty trivial to do. The equivalent
unbound python code for that would be:
import unbound
ctx = unbound.ub_ctx()
ctx.resolvconf("/this/networks/respresentation/of/resolv.conf")
Hmm, that doesn't really allow for split
On Thu, 18 Jun 2015, Dan Williams wrote:
The drawbacks I see to dnssec-trigger here are:
2) provides only HTTPS IPC, perhaps because it works on all platforms.
But a Linux-only solution would typically use a unix socket or D-Bus and
be secured by Unix or D-Bus permissions instead of using cer
On Fri, 2015-06-12 at 14:32 -0400, Paul Wouters wrote:
> On Fri, 12 Jun 2015, Dan Williams wrote:
>
> >> That is why HTTP redirection and DNS failure have to be detected by
> >> whatever is the "hot spot detector". Both items weigh in on triggering
> >> a hotspot logon window.
> >
> > Agreed. But
On Wed, 2015-06-17 at 13:17 +0200, Tomas Hozza wrote:
> On 12.06.2015 18:58, Dan Williams wrote:
> > On Fri, 2015-06-12 at 10:58 +0200, Tomas Hozza wrote:
> >> On 11.06.2015 22:48, Dan Williams wrote:
> >>> On Tue, 2015-06-09 at 12:30 -0400, Matthew Miller wrote:
> On Tue, Jun 09, 2015 at 11:3
On Mon, 2015-06-15 at 14:57 +0200, Petr Spacek wrote:
> On 12.6.2015 18:53, Dan Williams wrote:
> > On Fri, 2015-06-12 at 17:10 +0200, Petr Spacek wrote:
> >>> On Tue, 2015-06-09 at 12:30 -0400, Matthew Miller wrote:
> On Tue, Jun 09, 2015 at 11:34:39AM -0400, Paul Wouters wrote:
> > decis
- Original Message -
>
> Am 18.06.2015 um 17:17 schrieb Bastien Nocera:
> > - Original Message -
> >>
> >> Am 18.06.2015 um 15:29 schrieb Bastien Nocera:
> I would love to see more will for cooperation from GNOME people, so we
> can converge to the working and well inte
- Original Message -
> > > VPNs... done like 2 years ago. From what we discussed the connectivity
> > > checking is not really perfect in NM, since it assumes that DHCP
> > > provided resolvers are in resolv.conf because NM obviously uses system's
> > > stub resolver.
> > >
> > > If ther
- Original Message -
>
> Am 18.06.2015 um 15:29 schrieb Bastien Nocera:
> >> I would love to see more will for cooperation from GNOME people, so we
> >> can converge to the working and well integrated solution. Vague claims
> >> that something is missing or something needs to be done, wi
Am 18.06.2015 um 17:17 schrieb Bastien Nocera:
- Original Message -
Am 18.06.2015 um 15:29 schrieb Bastien Nocera:
I would love to see more will for cooperation from GNOME people, so we
can converge to the working and well integrated solution. Vague claims
that something is missing or
> > VPNs... done like 2 years ago. From what we discussed the connectivity
> > checking is not really perfect in NM, since it assumes that DHCP
> > provided resolvers are in resolv.conf because NM obviously uses system's
> > stub resolver.
> >
> > If there are any valid integration pieces, please
Am 18.06.2015 um 15:29 schrieb Bastien Nocera:
I would love to see more will for cooperation from GNOME people, so we
can converge to the working and well integrated solution. Vague claims
that something is missing or something needs to be done, without clear
reasoning is not helping anyone.
I
- Original Message -
>
>
> On 18.06.2015 13:14, Bastien Nocera wrote:
> >
> >
> > - Original Message -
> >> On 12.06.2015 19:00, Matthew Miller wrote:
> >>> On Fri, Jun 12, 2015 at 11:53:32AM -0500, Dan Williams wrote:
> Yeah, we did. From my recollection, most of that f
- Original Message -
> On 18.6.2015 13:14, Bastien Nocera wrote:
> >
> >
> > - Original Message -
> >> On 12.06.2015 19:00, Matthew Miller wrote:
> >>> On Fri, Jun 12, 2015 at 11:53:32AM -0500, Dan Williams wrote:
> Yeah, we did. From my recollection, most of that focused
On 18.06.2015 13:14, Bastien Nocera wrote:
>
>
> - Original Message -
>> On 12.06.2015 19:00, Matthew Miller wrote:
>>> On Fri, Jun 12, 2015 at 11:53:32AM -0500, Dan Williams wrote:
Yeah, we did. From my recollection, most of that focused on the unbound
parts and how NM could
On 18.6.2015 13:14, Bastien Nocera wrote:
>
>
> - Original Message -
>> On 12.06.2015 19:00, Matthew Miller wrote:
>>> On Fri, Jun 12, 2015 at 11:53:32AM -0500, Dan Williams wrote:
Yeah, we did. From my recollection, most of that focused on the unbound
parts and how NM could ad
- Original Message -
> On 12.06.2015 19:00, Matthew Miller wrote:
> > On Fri, Jun 12, 2015 at 11:53:32AM -0500, Dan Williams wrote:
> >> Yeah, we did. From my recollection, most of that focused on the unbound
> >> parts and how NM could add the dns=unbound stuff (which Pavel
> >> contrib
On 17.06.2015 16:22, Paul Wouters wrote:
> On Wed, 17 Jun 2015, Tomas Hozza wrote:
>
> >> While I don't actually care, this might well be a sticking point for
> >> many people since their DNS information is going to an untrusted (to
> >> them) DNS server. Yeah, I tend to trust Fedora, but not ever
On Wed, 17 Jun 2015, Tomas Hozza wrote:
While I don't actually care, this might well be a sticking point for
many people since their DNS information is going to an untrusted (to
them) DNS server. Yeah, I tend to trust Fedora, but not everyone will.
If you don't trust fedora infrastructure, yo
On 12.06.2015 18:58, Dan Williams wrote:
> On Fri, 2015-06-12 at 10:58 +0200, Tomas Hozza wrote:
>> On 11.06.2015 22:48, Dan Williams wrote:
>>> On Tue, 2015-06-09 at 12:30 -0400, Matthew Miller wrote:
On Tue, Jun 09, 2015 at 11:34:39AM -0400, Paul Wouters wrote:
> decision needs to then b
On 12.06.2015 19:17, Paul Wouters wrote:
> On 06/12/2015 12:53 PM, Dan Williams wrote:
>>> b) Broken networks:
>>> Some networks are so broken that even without captive portal they are not
>>> able
>>> to deliver DNSSEC data to the clients.
>>>
>>> In that case will try tunnel to other DNS servers
On 12.06.2015 19:00, Matthew Miller wrote:
> On Fri, Jun 12, 2015 at 11:53:32AM -0500, Dan Williams wrote:
>> Yeah, we did. From my recollection, most of that focused on the unbound
>> parts and how NM could add the dns=unbound stuff (which Pavel
>> contributed) but less on the NM connectivity che
On 12.06.2015 18:53, Dan Williams wrote:
> On Fri, 2015-06-12 at 17:10 +0200, Petr Spacek wrote:
>>> On Tue, 2015-06-09 at 12:30 -0400, Matthew Miller wrote:
On Tue, Jun 09, 2015 at 11:34:39AM -0400, Paul Wouters wrote:
> decision needs to then be made by the system. I believe that's been
On 12.06.2015 16:58, Paul Wouters wrote:
> On Fri, 12 Jun 2015, Matthew Miller wrote:
>
>> Another integration concern: the network config GUI (and ifcfg files,
>> for that matter) let me list specific DNS servers. With this
>> feature, are those used (and if so, how)? If not, is my configuration
On Tue, 16 Jun 2015, Bastien Nocera wrote:
That’s what dnssec-trigger ideally _should_ do. What would it _actually_
do, e.g. with the current code?
That's defined by login-command: in /etc/dnssec-trigger/dnssec-trigger.conf
which we did not change from the default "xdg-open".
It uses the URL
- Original Message -
> On Mon, 15 Jun 2015, Miloslav Trmač wrote:
>
> >> Detect it and show the sandboxed browser. If that means that the user
> >> has to type their Facebook password again, then the user is welcome to
> >> do that. I don't see why we should make it easier to track use
On Mon, 15 Jun 2015, Miloslav Trmač wrote:
Detect it and show the sandboxed browser. If that means that the user
has to type their Facebook password again, then the user is welcome to
do that. I don't see why we should make it easier to track users,
though.
That’s what dnssec-trigger ideally
> On Mon, Jun 15, 2015 at 3:02 PM, Miloslav Trmač wrote:
> > What would dnssec-trigger do if an attacker^Wlegitimate hotspot provider
> > deliberately let the hotspot probe lookup and connection through, but kept
> > redirecting everything else?
>
> Detect it and show the sandboxed browser. If t
> Apple (foolishly) used to use something like http://apple.com/hotspot
> on their main site itself, which meant that using a VPN on demand could
> never protect apple.com because the iphone had to leave that domain out
> of the vpn trigger list or else all hotspot detection would be broken. It
> s
On Mon, Jun 15, 2015 at 3:02 PM, Miloslav Trmač wrote:
> Hello,
>
> On Jun 13, 2015 4:28 AM, "Michael Catanzaro" wrote:
>> On Fri, 2015-06-12 at 15:49 -0700, Andrew Lutomirski wrote:
>> > >
>> > But that's not even right. Suppose you have a captive portal that
>> > wants you to log in via your G
Hello,
> On Jun 13, 2015 4:28 AM, "Michael Catanzaro" < mcatanz...@gnome.org > wrote:
> > On Fri, 2015-06-12 at 15:49 -0700, Andrew Lutomirski wrote:
> > > >
> > > But that's not even right. Suppose you have a captive portal that
> > > wants you to log in via your Google account. It can send you
> Generally the problem is that resolv.conf is quite limited and cannot express
> lot of things, like trust levels and per-domain forwarding (using different
> servers for queries related to different domains).
>
> One possibility how to solve this is to port applications to use different
> librar
On 15 June 2015 at 13:07, Paul Wouters wrote:
> On Mon, 15 Jun 2015, Stephen John Smoogen wrote:
>
>> Is the code on how ChromeOS or Android detects captivity part of the
>> 'public' code? It seems to do a 'good' job in finding many captive
>> portals so might be something to get an idea on how ma
On Mon, Jun 15, 2015 at 12:07 PM, Paul Wouters wrote:
> On Mon, 15 Jun 2015, Stephen John Smoogen wrote:
>
>> Is the code on how ChromeOS or Android detects captivity part of the
>> 'public' code? It seems to do a 'good' job in finding many captive
>> portals so might be something to get an idea o
On Mon, 15 Jun 2015, Stephen John Smoogen wrote:
Is the code on how ChromeOS or Android detects captivity part of the
'public' code? It seems to do a 'good' job in finding many captive
portals so might be something to get an idea on how many weird ways
things are out there.
I think everyone do
On 13 June 2015 at 17:10, Michael Catanzaro wrote:
> On Sat, 2015-06-13 at 15:54 -0400, Paul Wouters wrote:
>> If the captive portal uses the system's DNS, and the system has
>> cached
>> www.gnome.org from when you were on a previous network, your captive
>> portal check might use a cached DNS re
On 12.6.2015 18:53, Dan Williams wrote:
> On Fri, 2015-06-12 at 17:10 +0200, Petr Spacek wrote:
>>> On Tue, 2015-06-09 at 12:30 -0400, Matthew Miller wrote:
On Tue, Jun 09, 2015 at 11:34:39AM -0400, Paul Wouters wrote:
> decision needs to then be made by the system. I believe that's been
>
On 12.6.2015 16:55, Dan Williams wrote:
> On Fri, 2015-06-12 at 10:20 -0400, Matthew Miller wrote:
>> On Fri, Jun 12, 2015 at 10:58:14AM +0200, Tomas Hozza wrote:
>>> NetworkManager is pure network configuration manager in this scenario.
>>> We don't expect nor want NM to handle /etc/resolv.conf. W
On Sat, 13 Jun 2015, Michael Catanzaro wrote:
There is one thing I don't understand. Surely the above is exactly what
will happen if you were to get stuck behind a captive portal with
Firefox or any normal browser? But portals still work reliably for
users.
You should visit more hotels. The nu
On Sat, 2015-06-13 at 15:54 -0400, Paul Wouters wrote:
> If the captive portal uses the system's DNS, and the system has
> cached
> www.gnome.org from when you were on a previous network, your captive
> portal check might use a cached DNS resolve and try to use an HTTP
> connection to a blocked IP
On Sat, 13 Jun 2015, Michael Catanzaro wrote:
Hm... the captive portal helper loads www.gnome.org but it only runs
after NetworkManager has decided there is a captive portal. We can make
this URL configurable at build time if there's really a problem, but
I'm not sure there is, since it's not us
Am 13.06.2015 um 21:01 schrieb Michael Catanzaro:
There is a good reason we started hotspot-nocache.fedoraproject.org.
Hm... the captive portal helper loads www.gnome.org but it only runs
after NetworkManager has decided there is a captive portal. We can make
this URL configurable at build tim
On Sat, 2015-06-13 at 14:36 -0400, Paul Wouters wrote:
> using www.gnome.org is wrong. For one, you cannot guarantee they
> won't
> end up using some redirect and than the captive portal would fail.
I don't get it: what is wrong, what would fail? We expect them to
replace the contents of
www.gno
On Sat, 13 Jun 2015, Andrew Lutomirski wrote:
> It'd be nice to not show
> http://www.gnome.org (the test URL we load, expecting to be hijacked)
> if the portal decides not to redirect you to a new URI (not sure how
> common that is), but I think we will have to or we can't fix this
It coul
On Jun 13, 2015 4:28 AM, "Michael Catanzaro" wrote:
>
> On Fri, 2015-06-12 at 15:49 -0700, Andrew Lutomirski wrote:
> > >
> > But that's not even right. Suppose you have a captive portal that
> > wants you to log in via your Google account. It can send you do
> > https://accounts.google.com, and
On Fri, 2015-06-12 at 15:49 -0700, Andrew Lutomirski wrote:
> >
> But that's not even right. Suppose you have a captive portal that
> wants you to log in via your Google account. It can send you do
> https://accounts.google.com, and your browser can verify the
> certificate and show you an indic
On Fri, Jun 12, 2015 at 3:32 PM, Michael Catanzaro wrote:
> On Fri, 2015-06-12 at 11:19 -0700, Andrew Lutomirski wrote:
>> It wouldn't really have to be Firefox, but getting the browser chrome
>> right to avoid trivial phishing attacks is critical, and all real
>> browsers already do that fairly w
On Fri, 2015-06-12 at 11:19 -0700, Andrew Lutomirski wrote:
> It wouldn't really have to be Firefox, but getting the browser chrome
> right to avoid trivial phishing attacks is critical, and all real
> browsers already do that fairly well, whereas the simple embedded web
> views (e.g. gnome-shell-p
On Fri, 12 Jun 2015, Andrew Lutomirski wrote:
All that makes sense. Thanks.
FWIW, I think that a little C program to spin up a namespace that's
good enough to point a stateless Firefox instance at a captive portal
login with overridden DNS nameserver settings would only be a couple
of hundred
On Fri, 12 Jun 2015, Dan Williams wrote:
That is why HTTP redirection and DNS failure have to be detected by
whatever is the "hot spot detector". Both items weigh in on triggering
a hotspot logon window.
Agreed. But how does the DNS failure actually get relayed to the thing
doing the HTTP req
On Fri, Jun 12, 2015 at 10:33 AM, Dan Williams wrote:
> On Thu, 2015-06-11 at 14:41 -0700, Andrew Lutomirski wrote:
>> On Thu, Jun 11, 2015 at 1:48 PM, Dan Williams wrote:
>> > On Tue, 2015-06-09 at 12:30 -0400, Matthew Miller wrote:
>> >> On Tue, Jun 09, 2015 at 11:34:39AM -0400, Paul Wouters wr
On Fri, Jun 12, 2015 at 10:17 AM, Dan Williams wrote:
> On Fri, 2015-06-12 at 00:48 -0400, Paul Wouters wrote:
>> 2) NM/dnssec-trigger does the HTTP and DNS probing and prompting using
>> a dedicated container and any DNS requests in that container are
>> thrown away with the container onc
On Fri, 12 Jun 2015, Matthew Miller wrote:
I personally find the anchor icon very confusing. As a non-expert in
this area, it doesn't represent anything which seems relevant to me,
and all of the right click menu options, once I figured out to right
click, are obscure to me.
Agreed.
I don't
On Fri, 2015-06-12 at 12:17 -0500, Dan Williams wrote:
> > dnssec-trigger prompts the user with a choice of "allow insecure
> > DNS" or
> > "cache only mode". The latter means "no new DNS and use what's
> > already
> > in the cache only".
>
> Yeah, and the interaction story here has been controv
On Fri, 2015-06-12 at 13:00 -0400, Matthew Miller wrote:
> I hope we can get a design for this which integrates better with
> GNOME
> Shell and the existing network icon there.
Well we're just not going to ship this in Workstation if it breaks
NetworkManager's connectivity checking, nor will we s
On Thu, 2015-06-11 at 14:41 -0700, Andrew Lutomirski wrote:
> On Thu, Jun 11, 2015 at 1:48 PM, Dan Williams wrote:
> > On Tue, 2015-06-09 at 12:30 -0400, Matthew Miller wrote:
> >> On Tue, Jun 09, 2015 at 11:34:39AM -0400, Paul Wouters wrote:
> >> > decision needs to then be made by the system. I
On Fri, 2015-06-12 at 00:48 -0400, Paul Wouters wrote:
> On Thu, 11 Jun 2015, Dan Williams wrote:
>
> > Unfortunately the Proposal doesn't say anything about how this will
> > actually work, which is something NetworkManager needs to know. It also
> > fails to address the failure cases where your
On 06/12/2015 12:53 PM, Dan Williams wrote:
>> b) Broken networks:
>> Some networks are so broken that even without captive portal they are not
>> able
>> to deliver DNSSEC data to the clients.
>>
>> In that case will try tunnel to other DNS servers on the Internet (Fedora
>> Infra or public DNS r
On Fri, Jun 12, 2015 at 11:53:32AM -0500, Dan Williams wrote:
> Yeah, we did. From my recollection, most of that focused on the unbound
> parts and how NM could add the dns=unbound stuff (which Pavel
> contributed) but less on the NM connectivity checking, becuase Fedora
> hadn't turned that on by
On Fri, 2015-06-12 at 10:58 +0200, Tomas Hozza wrote:
> On 11.06.2015 22:48, Dan Williams wrote:
> > On Tue, 2015-06-09 at 12:30 -0400, Matthew Miller wrote:
> >> On Tue, Jun 09, 2015 at 11:34:39AM -0400, Paul Wouters wrote:
> >>> decision needs to then be made by the system. I believe that's been
On Fri, 2015-06-12 at 17:10 +0200, Petr Spacek wrote:
> > On Tue, 2015-06-09 at 12:30 -0400, Matthew Miller wrote:
> >> On Tue, Jun 09, 2015 at 11:34:39AM -0400, Paul Wouters wrote:
> >>> decision needs to then be made by the system. I believe that's been
> >>> mostly due to lack of time for the va
> On Tue, 2015-06-09 at 12:30 -0400, Matthew Miller wrote:
>> On Tue, Jun 09, 2015 at 11:34:39AM -0400, Paul Wouters wrote:
>>> decision needs to then be made by the system. I believe that's been
>>> mostly due to lack of time for the various parties to sit down and
>>> plan and then program this f
On 06/12/2015 11:10 AM, Petr Spacek wrote:
> HERE we need to coordinate with other parties who might want to write into the
> /etc/resolv.conf file. These include (but might not be limited to):
> NetworkManager
> initscripts
> dhclient
> libreswan ?
> resolved
> connman
>
On Fri, 12 Jun 2015, Matthew Miller wrote:
Another integration concern: the network config GUI (and ifcfg files,
for that matter) let me list specific DNS servers. With this
feature, are those used (and if so, how)? If not, is my configuration
just silently ignored?
I do not know if it is supp
On Fri, 2015-06-12 at 10:20 -0400, Matthew Miller wrote:
> On Fri, Jun 12, 2015 at 10:58:14AM +0200, Tomas Hozza wrote:
> > NetworkManager is pure network configuration manager in this scenario.
> > We don't expect nor want NM to handle /etc/resolv.conf. We will only get
> > the current network con
On Fri, Jun 12, 2015 at 10:58:14AM +0200, Tomas Hozza wrote:
> NetworkManager is pure network configuration manager in this scenario.
> We don't expect nor want NM to handle /etc/resolv.conf. We will only get
> the current network configuration from it and act upon it. NM
> configuration will conta
On Fri, Jun 12, 2015 at 09:57:38AM -0400, Paul Wouters wrote:
> Did your networking actually break, or just the notification icon status?
It will definitely break on F22 without the updated SELinux or SELinux
in permissive mode.
--
Matthew Miller
Fedora Project Leader
--
devel mailing list
de
On Fri, 2015-06-12 at 09:57 -0400, Paul Wouters wrote:
> On Fri, 12 Jun 2015, Matthias Clasen wrote:
>
> > I've just installed dnssec-trigger on rawhide to try this out, and
> > found that it breaks networking on my Workstation. I used to get a
> > network connection on login, now I get a question
On Fri, 12 Jun 2015, Matthias Clasen wrote:
I've just installed dnssec-trigger on rawhide to try this out, and
found that it breaks networking on my Workstation. I used to get a
network connection on login, now I get a question mark in top bar, and
a status icon with obsure menu options appears.
On Fri, 2015-06-12 at 10:58 +0200, Tomas Hozza wrote:
>
> > 3. NM waits for some signal from unbound/dnssec-trigger about the
> > trustability of the DNS server
>
> If you think NM needs to do some action (as I don't), we don't have
> problem with notifying NM (if you provide some API).
>
This
On 11.06.2015 22:48, Dan Williams wrote:
> On Tue, 2015-06-09 at 12:30 -0400, Matthew Miller wrote:
>> On Tue, Jun 09, 2015 at 11:34:39AM -0400, Paul Wouters wrote:
>>> decision needs to then be made by the system. I believe that's been
>>> mostly due to lack of time for the various parties to sit
On Thu, 11 Jun 2015, Dan Williams wrote:
Unfortunately the Proposal doesn't say anything about how this will
actually work, which is something NetworkManager needs to know. It also
fails to address the failure cases where your local DNS doesn't support
DNSSEC or is otherwise broken here out of
On Thu, Jun 11, 2015 at 1:48 PM, Dan Williams wrote:
> On Tue, 2015-06-09 at 12:30 -0400, Matthew Miller wrote:
>> On Tue, Jun 09, 2015 at 11:34:39AM -0400, Paul Wouters wrote:
>> > decision needs to then be made by the system. I believe that's been
>> > mostly due to lack of time for the various
On Tue, 2015-06-09 at 12:30 -0400, Matthew Miller wrote:
> On Tue, Jun 09, 2015 at 11:34:39AM -0400, Paul Wouters wrote:
> > decision needs to then be made by the system. I believe that's been
> > mostly due to lack of time for the various parties to sit down and
> > plan and then program this furt
On 11.6.2015 07:39, P J P wrote:
>Hello Miloslav,
>
>> On Wednesday, 10 June 2015 8:55 PM, Miloslav Trmač wrote:
>> We’ve had earlier conversations about whether the resolver being used (local,
>> remote, container host) is trusted to perform DNSSEC validation. How is this
>> resolved? The Ch
Hello Miloslav,
> On Wednesday, 10 June 2015 8:55 PM, Miloslav Trmač wrote:
> We’ve had earlier conversations about whether the resolver being used (local,
> remote, container host) is trusted to perform DNSSEC validation. How is this
> resolved? The Change page AFAICS doesn’t say.
>
> Do you
Hello,
> = Proposed System Wide Change: Default Local DNS Resolver =
> https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
>
> Install a local DNS resolver trusted for the DNSSEC validation running on
> 127.0.0.1:53. This must be the only name server entry in /etc/resolv.conf.
We’v
On Tue, Jun 09, 2015 at 11:34:39AM -0400, Paul Wouters wrote:
> decision needs to then be made by the system. I believe that's been
> mostly due to lack of time for the various parties to sit down and
> plan and then program this further.
We should try to make that happen.
>
> >I see that there
On Tue, 9 Jun 2015, Matthew Miller wrote:
One (new!) thing I'm concerned with, now that I've enabled it on my
system, is the persistant tray notification. This is... confusing and
ugly. Can we (for F23 if possible, and F24 if not) get better GNOME
Shell integration here?
That's been on the TOD
On Tue, Jun 09, 2015 at 01:23:22PM +0200, Vít Ondruch wrote:
> > As per F23 schedule, it's post 28 Jul 2015
> > -> https://fedoraproject.org/wiki/Releases/23/Schedule
>
> That is the latst possible date when it should be definitely available.
> I can't see any reason why it should not be possi
Dne 9.6.2015 v 13:18 P J P napsal(a):
> Hello Vit,
>
>
>> On Tuesday, 9 June 2015 12:22 PM, Vít Ondruch wrote:
>> I hope that I won't need to do this steps manually after F23
>> installation, otherwise it could be hardly called "default". So when
>> there will be available final version which doe
Hello Vit,
> On Tuesday, 9 June 2015 12:22 PM, Vít Ondruch wrote:
> I hope that I won't need to do this steps manually after F23
> installation, otherwise it could be hardly called "default". So when
> there will be available final version which does not need any additional
> configuration ava
Dne 1.6.2015 v 14:03 Jan Kurik napsal(a):
> = Proposed System Wide Change: Default Local DNS Resolver =
> https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
>
>
The "How To Test" section now contains a lot of steps such as "configure
NM", "enable/disable service", but when there wil
On Wed, 2015-06-03 at 14:07 +0200, Reindl Harald wrote:
> Am 03.06.2015 um 14:02 schrieb Petr Spacek:
> > On 3.6.2015 13:45, Reindl Harald wrote:
> >>> I'm sorry for disappointing you.
> >>>
> >>> The behavior I describe is standard for last ~ 20 years 1987 (RFCs
> >>> 1034/1035/2308). If you don't
On Wed, 3 Jun 2015, Petr Spacek wrote:
It is somewhat questionable whether DNS rebinding vulnerabilities are,
in fact, a problem which should be solved at the client side. But
Oh yes. DNS pinning in browser is just a band-aid and not proper solution. I
would argue that DNS rebinding attack is
On Wed, 3 Jun 2015, Petr Spacek wrote:
???On 3.6.2015 13:45, Reindl Harald wrote:
If you feel that the standard is broken then *please* continue with discussion
on IETF's dnsop mailing list:
https://www.ietf.org/mailman/listinfo/dnsop
come on stop trolling that way because you know exactly
Am 03.06.2015 um 14:02 schrieb Petr Spacek:
On 3.6.2015 13:45, Reindl Harald wrote:
I'm sorry for disappointing you.
The behavior I describe is standard for last ~ 20 years 1987 (RFCs
1034/1035/2308). If you don't agree with standard then you cannot use DNS
technology as standardized. Here I'm
On 3.6.2015 13:45, Reindl Harald wrote:
>
> Am 03.06.2015 um 13:39 schrieb Petr Spacek:
>> On 3.6.2015 10:58, Reindl Harald wrote:
>>>
>>> Am 03.06.2015 um 09:14 schrieb Petr Spacek:
> so with setup a dns cache on each and every machine you fuckup your
> network
> because you introduc
On 3.6.2015 12:04, Florian Weimer wrote:
> On 06/02/2015 08:36 PM, Paul Wouters wrote:
>> On Tue, 2 Jun 2015, Simo Sorce wrote:
>>
and just because you have a local resolver firefox won't stop it's
behavior
>>>
>>> It can, w/o a local resolver FF developers will definitely keep caching
>>
Am 03.06.2015 um 13:39 schrieb Petr Spacek:
On 3.6.2015 10:58, Reindl Harald wrote:
Am 03.06.2015 um 09:14 schrieb Petr Spacek:
so with setup a dns cache on each and every machine you fuckup your network
because you introduce the same negative TTL caching affecting OSX clients for
years now
On 3.6.2015 10:58, Reindl Harald wrote:
>
> Am 03.06.2015 um 09:14 schrieb Petr Spacek:
>>> so with setup a dns cache on each and every machine you fuckup your network
>>> because you introduce the same negative TTL caching affecting OSX clients
>>> for
>>> years now
>>
>> Please let me clarify f
On 06/02/2015 08:36 PM, Paul Wouters wrote:
> On Tue, 2 Jun 2015, Simo Sorce wrote:
>
>>> and just because you have a local resolver firefox won't stop it's
>>> behavior
>>
>> It can, w/o a local resolver FF developers will definitely keep caching
>> on their own, with a decent local resolver they
Am 03.06.2015 um 09:14 schrieb Petr Spacek:
so with setup a dns cache on each and every machine you fuckup your network
because you introduce the same negative TTL caching affecting OSX clients for
years now
Please let me clarify few things:
1) Negative caching is controlled by zone owner. If
On 1.6.2015 20:58, Reindl Harald wrote:
>
> Am 01.06.2015 um 20:30 schrieb Andrew Lutomirski:
>> On Mon, Jun 1, 2015 at 11:02 AM, Reindl Harald
>> wrote:
>>>
>>> Am 01.06.2015 um 19:55 schrieb Jason L Tibbitts III:
>
> "RSB" == Ryan S Brown writes:
RSB> I disagree
On Tue, 2 Jun 2015, David Howells wrote:
I'm using dnsmasq to look up *.redhat.com addresses over VPN whilst looking up
other addresses from my ISP.
That is automatically handled for you if you use libreswan for your
VPN and unbound is running. It will add a forward for the domain
("redhat.com
Paul Wouters wrote:
> I think most people end up running dnsmasq because of KVM/libvirtd ? I
> think those dnsmasq's should be run in "dhcp only" mode and point to
> the hosts's unbound.
I'm using dnsmasq to look up *.redhat.com addresses over VPN whilst looking up
other addresses from my ISP.
On Tue, Jun 02, 2015 at 08:12:23PM +0200, Reindl Harald wrote:
> >>the whole purpose of Linux systems was to have open systems, open means also
> >>basically understandable and not just "you can grab the source"
> >
> >Linux is not, and has never been, UNIX
>
> your phrase has nothing to with the
On Tue, 2 Jun 2015, Simo Sorce wrote:
and just because you have a local resolver firefox won't stop it's behavior
It can, w/o a local resolver FF developers will definitely keep caching
on their own, with a decent local resolver they can allow themselves to
disable their own and go back to rel
Am 02.06.2015 um 20:04 schrieb Solomon Peachy:
On Tue, Jun 02, 2015 at 07:56:21PM +0200, Reindl Harald wrote:
the whole purpose of Linux systems was to have open systems, open means also
basically understandable and not just "you can grab the source"
Linux is not, and has never been, UNIX
y
On Tue, 2015-06-02 at 19:56 +0200, Reindl Harald wrote:
> Am 02.06.2015 um 19:49 schrieb Simo Sorce:
> > On Mon, 2015-06-01 at 23:15 +0200, Reindl Harald wrote:
> >> a sane system should be as simple as possible so that *one* human is
> >> able to determine what is happening without hire 10 special
On Tue, Jun 02, 2015 at 07:56:21PM +0200, Reindl Harald wrote:
> the whole purpose of Linux systems was to have open systems, open means also
> basically understandable and not just "you can grab the source"
Linux is not, and has never been, UNIX.
- Solomon
--
Solomon Peachy
1 - 100 of 138 matches
Mail list logo
