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.