Web lists-archives.com

Re: (solved) Re: wireless fail after stretch installation




At some point Jude DaShiell Cc'ed -devel. This accounts for some of the
traffic in this thread. I am also Cc'ing -devel. You didn't, but I am
not trimming any of your post; nor am I replying to every portion in
it.


On Sat 10 Mar 2018 at 09:53:58 -0600, David Wright wrote:

> On Wed 07 Mar 2018 at 13:25:16 (+0000), Ian Jackson wrote:
> > bw writes ("Re: (solved) Re: wireless fail after stretch installation"):
> > > On Tue, 6 Mar 2018, Brian wrote:
> > > > One user calls it a "sick joke". After five years and with no attempt
> > > > to rectify the situation, I'm beginning to have sympathy with that view.
> > 
> > Debian, like all ordinary software, is full of bugs.  Many bugs
> > languish unfixed for years.  This is not malice, or a "sick joke".
> > It's just that there is too much to do and too few people to do it.
> 
> I'm afraid I've been misquoted. The exchange was (my lines are marked ★):
> 
> --✄--------
> 
> > How connectivity is re-established on a machine with only a wireless
> > interface is left as an exercise for the user.
> 
> This is some sort of sick joke. ★
> 
> --✄--------
> 
> https://lists.debian.org/debian-user/2018/02/msg00015.html

Many apologies for quoting out of context.

> > There are rare cases where horrible people deliberately sabotage
> > things.  They are very high profile because they are so outrageous,
> > but they are not the norm.  I see no evidence in relation to this bug
> > that anyone is sabotaging anything.
> 
> I made no accusations of sabotage. Again:
> 
> --✄--------
> 
> > > > So this must be intentioal, wouldn't you say?
> > > 
> > > No. ★
> 
> […]
> 
> > > > And this is also clearly intentional.
> > > 
> > > Intended to do what? ★
> > 
> > To leave the user without network connectivity after first boot? There
> > are at least three bug reports against netcfg on the matter. My
> > recollection is that no deeper intention is revealed there.
> 
> […]

The word "deliberately" was picked up and labelled as giving the message
an unfortunate tone and then linked with "deliberately breaking stuff".
A deliberate action need not be done with malice and there was nothing
in what I said which put ill-intent forward as a reason.

> Yes, I don't think the intentions are deeper, but just that simple ★
> cases have been overlooked, and overlooked for several years. ★
> 
> --✄--------
> 
> The thing that seemed odd to me when I examined the log was that the
> installer removed the wireless configuration right at the last moment,
> with no method of circumventing it.


> 
> On discovering the udeb package called netcfg and looking through its
> bugs, it seemed that the network connection was torn down (with good
> reason, to do with DHCP leases perhaps) but then the configuration
> itself was also torn down, and this was considered a good thing for
> reasons I couldn't fathom, and which seemed to forget the case of a
> wireless interface and its intended future use of ifupdown with /e/n/i
> after rebooting.
> 
> > The correct approach to this bug is to figure out how to fix it, and
> > send a patch.
> > 
> > > Brute forcing this thing with wifi to /e/n/i might not be the best 
> > > approach?  What about people who want a different config than the 
> > > installer?  What about people who don;t want to be UP (auto) on bootup?  
> > > What about static configs?  Wifi is by nature a mobile environment, what 
> > > about security or several devices?  Let's help the devs by hashing out the 
> > > pros and cons and making a coherent proposal?
> > 
> > We are considering the situation where the user has installed a
> > barebones system, with no GUI network management tools.
> > 
> > Such a user will probably *expect* to edit a configuration file when
> > they want to change their network configuration, whether because their
> > needs change, or because their needs are different to those of the
> > majority of people.
> > 
> > Consequently, there is no problem in principle with setting up /e/n/i
> > to have the wifi configuration from the install.  That is what most
> > people who do this will want; and if it doesn't suit them, they can
> > change it.  (It is easier to change it or delete it, than it is to set
> > it up from scratch.)
> 
> Yes, that's just what I had originally expected, and would be great.
> 
> > AFAICT from reading #694068, the reason d-i currently strips this
> > information out of the installed system is because it contains the
> > wifi password in /e/n/i, a world-readable file.  That would obviously
> > be wrong.
> 
> The odd thing about this reasoning was that I seem to recall several
> generations ago (more than ten years?) finding that /e/n/i was not
> world-readable upon installation. (If this was when I was using ppp/
> mgetty/CHAPS etc, it would be pre-2004. I could be misremembering here.)
> 
> > Someone should implement and test the suggestion made by Trent Buck,
> > here,
> >   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694068#47
> > 
> > Specifically:
> > 
> > |  If you don't want to udebify wpa_passphrase, you can do it by hand:
> > |
> > |      cat >"/etc/wpa_supplicant/wpa_supplicant-$iface.conf" <<EOF
> > |      network={
> > |	 ssid="$ssid"
> > |	 psk="$passphrase"
> > |      }
> > |      EOF
> > 
> > This should be arranged in the appropriate bit of d-i, so that the
> > installed system works the same way as the installer.
> 
> That would be a great improvement, and with least surprise.
> 
> BTW if you read right to the end of
> https://lists.debian.org/debian-user/2018/02/msg00015.html
> the last sentence is meant to be a reference to our
> Great Leader's Orwellian press briefings.

Trent W. Buck said in #694068:

  > This issue's history seems to be bogged down on whether
  > interfaces(5) can be mode 0600 (to hide the cleartext
  > passphrase).

As can be seen from
 
 https://lists.debian.org/debian-boot/2012/09/msg00282.html

having mode 0600 for /e/n/i was not given as a reason.

Futher on in the thread is:

 https://lists.debian.org/debian-boot/2012/09/msg00313.html

  > IIRC we decided on this default before we added the code to
  > change the access mode of /e/n/i if it contains a password.
  > The main reason for defaulting to no configuration in
  > this case was to avoid having passwords in there. If people
  > think it should default to ifupdown in this case this can be
  > changed.

Nothing about mode 0600 as a reason for the design and there was a
willingness to change the default.

You said earlier:

 > The thing that seemed odd to me when I examined the log was that the
 > installer removed the wireless configuration right at the last moment,
 > with no method of circumventing it.

That is touched on in the same -boot thread.

-- 
Brian.