On 02/22/2018 08:09 AM, Yuraeitha wrote:
> On Thursday, February 22, 2018 at 3:20:32 AM UTC+1, Max Andersen wrote:
>> Sendt fra min iPhone
>>> Den 21. feb. 2018 kl. 21.23 skrev Yuraeitha <yuraei...@gmail.com>:
>>>> On Wednesday, February 21, 2018 at 8:13:44 PM UTC+1, Max Andersen wrote:
>>>> I've noticed that after disabling SSID broadcast on my wifi, I need to
>>>> disable and reenable my network, every time I login.
>>>> I've tried to describe it in detail here: https://militant.dk/?p=174
>>>> Maybe anyone has ideas to resolve this?
>>> Think of it this way. Hackers love challenges. By the act of trying to hide
>>> that way, you're giving a hacker a challenge. He or she, may even get a
>>> kick out of showing you how insecure your network really is by messing with
>>> you, simply because you do something that has no effect, such as hiding the
>>> You're either giving them a challenge to work on, or it might even be
>>> schadenfreude https://en.wikipedia.org/wiki/Schadenfreude
>>> Tbh, you're better off just enabling SSID again.
>> So, the solution is actually security by nudging?
>> Don’t do it, or we will make qubes network manager crash to nudge you back :)
>> I’d bet my network is not that interesting for a wardriving kali hacker, but
>> it still seem like a bug that I would love to get fixed.
> hehe, well you can probably find a hack to get what you need, for example
> making a script that automatically repairs your connection at boot. I'm not
> seeing the particular details atm, but it seems like it might just work. I'm
> no expert though.
> The bug itself is likely not related to Qubes btw. It's very likely that it
> belongs upstream in Fedora, and even in Fedora the Network Manager may come
> from up further upstream. Even if you track down the Network Manager
> developers, the piece of code they're using may come even further upstream,
> and even there, it may yet again come from another upstream. This is usually
> called upstream/downstream movements. Linux is like lego, many pieces comes
> elsewhere, and no one have the resources to do everything. If they tried,
> they'd drawn in work to do. And if they change upstream code, then it becomes
> really, really messy when new updates arrive from upstream, and you need to
> incorporate the code changes you made to all your packages every time a new
> update arrives. To make matters worse, it's not their code, so it can be hard
> to find your way around and find the right places in the code, wasting a lot
> of time. And then there is the aspect that security can be tough to enforce
> if you spread out too far. You have to trust other developers to some extent,
> otherwise you'd spend all your time looking for security flaws and never get
> anything else done.
> The closer to you get to the source upstream, the higher your odds are that a
> developer will track it down and report the issue. Qubes is pretty far away
> from the source, and operates on a more broad level of coding
> (macro-perspective, piecing a lot of different codes and mechanism together).
> You can kind of look at Qubes as an infrastructure, and not an organ like
> operation systems are. Qubes in and on itself is not an operation system,
> it's a network or "mesh" of operation systems. So this issue has to be
> tracked down.
> It's also an issue if developers have to spend time reporting all the bugs to
> each others, they'd spend a huge amount of time on that. A single bug may not
> seem like wasting a lot of time, but it piles up. Say one spends 20 dollars,
> it's pennies, not a lot of money (well at least in some countries). Now
> imagine if you had to pay for 1.000 pieces, then it becomes 20.000 dollars,
> and it suddenly became very expensive.
> That's why developers have to prioritize their time and focus, because if
> they do not, they'd drawn in everything else. Qubes top priority is security.
> I doubt they will be looking into this bug.
> But the community can help, by reporting the bug closer to the source, or at
> the actual source. This way the bug can get fixed, and it may go faster too
> (not always though) if the actual developers behind it are reported about it
> directly. If the community does this, it'll save all developers a huge amount
> of time. So this kind of bug, may be a matter of tracking down the actual
> Network Manager developers.
> But if you'd like a fix though, a sort of "hack", then as mentioned earlier,
> a script may work out. But before trying to look into it, I'll ask if this is
> something you need? or do you prefer to wait for a real bug fix? (It can take
> a long time for what may be deemed minor bugs, and also requires someone
> reporting it at the appropriate issue-tracker).
> I may not be able to make such a script though, I'm only an average Linux
> user. But I'll try see if I can work something out, however,
> sleep/work/responsibilities up ahead, and things I gotta do, so it might take
> a while before I can find time to see if I can work out how to do it or not.
> Maybe someone else knows how and drops a solution meanwhile (would be nice
> too). But then, is a script kicking in at boot to fix your network
> credentials something you'd want?
Thank you for your offer, but Instead of spending too much time on it,
the nudging approach worked. Made the network visible, change the name
to not include manufacturer and model name to decrease the attack vector
was the easiest fix.
But for people needing such a workaround, the idea could be:
Placed in .bash_profile, /etc/profile, gnome-session-properties,
.config/autostart or somewhere else so it executes directly after login
echo "Checking network..."
if ping -c 2 $ROUTER_IP
systemctl network restart
Thanks for your time
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to email@example.com.
To view this discussion on the web visit
For more options, visit https://groups.google.com/d/optout.