Re: Status update {Re: PARTIAL DIAGNOSIS of Installation problems}

[Andrew M.A. Cater]

On Wed, Mar 10, 2021 at 04:26:06AM -0600, Richard Owlett wrote:
> On 03/10/2021 03:45 AM, Andrei POPESCU wrote:
> > On Ma, 09 mar 21, 14:35:54, Richard Owlett wrote:
> > > On 03/09/2021 07:00 AM, Andrei POPESCU wrote:
> > > > On Ma, 09 mar 21, 06:32:33, Richard Owlett wrote:
> > > > > On 03/08/2021 10:18 AM, songbird wrote:
> > > > > > Richard Owlett wrote:
> > > > > > ...
> > > > > > 
> > > > > > before chasing down this rabbit hole, see if there is an
> > > > > > upgrade for your current kernel on the debian backports
> > > > > > site (for your processor and distribution type).  i just
> > > > > > had an issue with a new device not being recognized and
> > > > > > updated my kernel (for stretch) and it worked fine after
> > > > > > that.
> > > > > > 
> > > > > 
> > > > > The more I think about my observed symptoms, it would seem logical to 
> > > > > be
> > > > > kernel related.
> > > > > 
> > > > > If the Linkzone is physically connected when PC is turned on, the boot
> > > > > process will hang until the Linkzone is disconnected.
> > > > 
> > > > Please also provide info like the exact stage of the boot process, any
> > > > (error) messages on screen, etc.
> > > > 
> > > > I've seen this symptom with a laptop before, though it would hang at the
> > > > BIOS stage (it was probably trying to boot from it), while you imply
> > > > it's later.
> > > 
> > > I think there are 2 separate states of the Linkzone may have when 
> > > attempting
> > > to boot the PC.
> > > 
> > > 1. The Linkzone is off but plugged into the PC.
> > > Boot appeared normal.
> > > 
> > > 2. The Linkzone is turned on and I have waited for its indicator lights to
> > > indicate connection to network.
> > >  This time the the screen was looping very quickly repeating that it 
> > > was
> > > attempting to reset a USB device.
> > > 
> > > What log should I look in for such an error message?
> > > I know I've seen description of how to interpret the boot process to 
> > > gather
> > > information. But where?
> > 
> > The boot process has three major stages.
> > 
> > 1. POST: https://en.wikipedia.org/wiki/Power-on_self-test
> > 2. Bootloader (grub, etc.)
> > 3. Operating System (in this case Debian)
> > 
> > In which of the above stages does the boot hang?
> 
> In yesterday's case, it was definitely case 3.
> In the case of getting a hang with blank screen I suspect it also was case
> 3, but I wasn't recording detailed symptoms the last time it happened.
> 
> I all cases I've heard the beep from POST.
> 
> > 
> > > I suspect also there is a subset of Case 2 -- The LinkZone had been used 
> > > to
> > > interact with a website before being plugged into the PC under test.
> > 
> > Sorry, can't imagine how a modem can be used to "interact with a web
> > page" without being connected to a PC.
> 
> Consider this sequence of events.
> 1. PC and LinkZone powered off
> 2. Turn on PC
> 3. Debian boots normally
> 4. Turn on LinkZone
> 5. Browse a web site
> 6. Shut off PC power leaving LinkZone running on its battery
> 7. Wait
> 8. Turn on PC
> 9. Failure occurs
> 
Consider that the 4G connectivity device from the ISP probably needs to be on
BEFORE the PC connects to it. [I swear we've had almost exactly this message
before in one of the other threads].

The hotspot connects to 4G then serves out DHCP addresses - if you were using
WiFi, you'd get a WiFi connection. The hotspot is probably not meant to be
switched on and off repeatedly but to be used for a peroiod of hours 
per session.

1. Turn hotspot on. Check that it is working by using the app and/or 
connecting another device and checking connectivity.

2. Boot Debian.

3. Obtain Web connectivity *Profit*

If you're turning the PC on and off with a USB device physically connected, 
it's no wonder that things get confused - *especially* if USB enumeration
is unclear as to what sort of device it is.

I note also that you apparently have a cap of 2GB per month: in that situation
I'd not use a netinst to install anything but it does seem a crazily low
data amount for 30 days.

> 

All best, as ever,

Andy C.

Re: Status update {Re: PARTIAL DIAGNOSIS of Installation problems}

[Andrei POPESCU]

On Mi, 10 mar 21, 08:49:06, Richard Owlett wrote:
> 
> Looking at /usr/share/doc/systemd/README.Debian prompts me to ask:
>  "What logs might be created when attempting to run a netinst.iso?"

The Debian Installation Guide should have more information on the 
Installer's logs and where they are to be found on the final install.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Status update {Re: PARTIAL DIAGNOSIS of Installation problems}

[Richard Owlett]

On 03/10/2021 07:29 AM, Andrei POPESCU wrote:

On Mi, 10 mar 21, 04:26:06, Richard Owlett wrote:

On 03/10/2021 03:45 AM, Andrei POPESCU wrote:


The boot process has three major stages.

1. POST: https://en.wikipedia.org/wiki/Power-on_self-test
2. Bootloader (grub, etc.)
3. Operating System (in this case Debian)

In which of the above stages does the boot hang?


In yesterday's case, it was definitely case 3.
In the case of getting a hang with blank screen I suspect it also was case
3, but I wasn't recording detailed symptoms the last time it happened.

I all cases I've heard the beep from POST.


Well, it should be pretty obvious if you are past the bootloader (grub)
stage or not ;)

Assuming the hang happens in the OS stage a first step would be to
remove 'quiet' from the boot command line. Both the kernel and systemd
(assuming the boot is progressing that far) should be significantly more
verbose then.
  

Consider this sequence of events.
1. PC and LinkZone powered off
2. Turn on PC
3. Debian boots normally
4. Turn on LinkZone
5. Browse a web site
6. Shut off PC power leaving LinkZone running on its battery
7. Wait
8. Turn on PC
9. Failure occurs


After a failed boot you could try to boot normally and check the output
of

 journalctl -alb -1

('-1' means the logs from the previous boot)

Based on the timestamps you should be able to determine whether this is
the failed boot (assuming it got far enough to save the logs to
persistent storage) or the previous one.

This may not work unless you enable persistent storage for
systemd-journal (see /usr/share/doc/systemd/README.Debian).



I may not be able to do until tomorrow as I have errands to run before 
much rain in next several days.


Looking at /usr/share/doc/systemd/README.Debian prompts me to ask:
 "What logs might be created when attempting to run a netinst.iso?"

I have a spare laptop whose HDD I can wipe and use for experiments.
My  mindset still shows influence of doing component level debug in 
mid/late 70's. I just have no pre-retirement *nix experience.


Any other reading assignments?

My motto:
If retirement is not for learning, what use is it? 

Re: Status update {Re: PARTIAL DIAGNOSIS of Installation problems}

[Andrei POPESCU]

On Mi, 10 mar 21, 04:26:06, Richard Owlett wrote:
> On 03/10/2021 03:45 AM, Andrei POPESCU wrote:
> > 
> > The boot process has three major stages.
> > 
> > 1. POST: https://en.wikipedia.org/wiki/Power-on_self-test
> > 2. Bootloader (grub, etc.)
> > 3. Operating System (in this case Debian)
> > 
> > In which of the above stages does the boot hang?
> 
> In yesterday's case, it was definitely case 3.
> In the case of getting a hang with blank screen I suspect it also was case
> 3, but I wasn't recording detailed symptoms the last time it happened.
> 
> I all cases I've heard the beep from POST.

Well, it should be pretty obvious if you are past the bootloader (grub) 
stage or not ;)

Assuming the hang happens in the OS stage a first step would be to 
remove 'quiet' from the boot command line. Both the kernel and systemd 
(assuming the boot is progressing that far) should be significantly more 
verbose then.
 
> Consider this sequence of events.
> 1. PC and LinkZone powered off
> 2. Turn on PC
> 3. Debian boots normally
> 4. Turn on LinkZone
> 5. Browse a web site
> 6. Shut off PC power leaving LinkZone running on its battery
> 7. Wait
> 8. Turn on PC
> 9. Failure occurs

After a failed boot you could try to boot normally and check the output 
of

journalctl -alb -1

('-1' means the logs from the previous boot)

Based on the timestamps you should be able to determine whether this is 
the failed boot (assuming it got far enough to save the logs to 
persistent storage) or the previous one.

This may not work unless you enable persistent storage for 
systemd-journal (see /usr/share/doc/systemd/README.Debian).

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Status update {Re: PARTIAL DIAGNOSIS of Installation problems}

[Richard Owlett]

On 03/10/2021 03:45 AM, Andrei POPESCU wrote:

On Ma, 09 mar 21, 14:35:54, Richard Owlett wrote:

On 03/09/2021 07:00 AM, Andrei POPESCU wrote:

On Ma, 09 mar 21, 06:32:33, Richard Owlett wrote:

On 03/08/2021 10:18 AM, songbird wrote:

Richard Owlett wrote:
...

before chasing down this rabbit hole, see if there is an
upgrade for your current kernel on the debian backports
site (for your processor and distribution type).  i just
had an issue with a new device not being recognized and
updated my kernel (for stretch) and it worked fine after
that.



The more I think about my observed symptoms, it would seem logical to be
kernel related.

If the Linkzone is physically connected when PC is turned on, the boot
process will hang until the Linkzone is disconnected.


Please also provide info like the exact stage of the boot process, any
(error) messages on screen, etc.

I've seen this symptom with a laptop before, though it would hang at the
BIOS stage (it was probably trying to boot from it), while you imply
it's later.


I think there are 2 separate states of the Linkzone may have when attempting
to boot the PC.

1. The Linkzone is off but plugged into the PC.
Boot appeared normal.

2. The Linkzone is turned on and I have waited for its indicator lights to
indicate connection to network.
 This time the the screen was looping very quickly repeating that it was
attempting to reset a USB device.

What log should I look in for such an error message?
I know I've seen description of how to interpret the boot process to gather
information. But where?


The boot process has three major stages.

1. POST: https://en.wikipedia.org/wiki/Power-on_self-test
2. Bootloader (grub, etc.)
3. Operating System (in this case Debian)

In which of the above stages does the boot hang?


In yesterday's case, it was definitely case 3.
In the case of getting a hang with blank screen I suspect it also was 
case 3, but I wasn't recording detailed symptoms the last time it happened.


I all cases I've heard the beep from POST.




I suspect also there is a subset of Case 2 -- The LinkZone had been used to
interact with a website before being plugged into the PC under test.


Sorry, can't imagine how a modem can be used to "interact with a web
page" without being connected to a PC.


Consider this sequence of events.
1. PC and LinkZone powered off
2. Turn on PC
3. Debian boots normally
4. Turn on LinkZone
5. Browse a web site
6. Shut off PC power leaving LinkZone running on its battery
7. Wait
8. Turn on PC
9. Failure occurs

Re: Status update {Re: PARTIAL DIAGNOSIS of Installation problems}

[Andrei POPESCU]

On Ma, 09 mar 21, 14:35:54, Richard Owlett wrote:
> On 03/09/2021 07:00 AM, Andrei POPESCU wrote:
> > On Ma, 09 mar 21, 06:32:33, Richard Owlett wrote:
> > > On 03/08/2021 10:18 AM, songbird wrote:
> > > > Richard Owlett wrote:
> > > > ...
> > > > 
> > > > before chasing down this rabbit hole, see if there is an
> > > > upgrade for your current kernel on the debian backports
> > > > site (for your processor and distribution type).  i just
> > > > had an issue with a new device not being recognized and
> > > > updated my kernel (for stretch) and it worked fine after
> > > > that.
> > > > 
> > > 
> > > The more I think about my observed symptoms, it would seem logical to be
> > > kernel related.
> > > 
> > > If the Linkzone is physically connected when PC is turned on, the boot
> > > process will hang until the Linkzone is disconnected.
> > 
> > Please also provide info like the exact stage of the boot process, any
> > (error) messages on screen, etc.
> > 
> > I've seen this symptom with a laptop before, though it would hang at the
> > BIOS stage (it was probably trying to boot from it), while you imply
> > it's later.
> 
> I think there are 2 separate states of the Linkzone may have when attempting
> to boot the PC.
> 
> 1. The Linkzone is off but plugged into the PC.
>Boot appeared normal.
> 
> 2. The Linkzone is turned on and I have waited for its indicator lights to
> indicate connection to network.
> This time the the screen was looping very quickly repeating that it was
> attempting to reset a USB device.
> 
> What log should I look in for such an error message?
> I know I've seen description of how to interpret the boot process to gather
> information. But where?

The boot process has three major stages.

1. POST: https://en.wikipedia.org/wiki/Power-on_self-test
2. Bootloader (grub, etc.)
3. Operating System (in this case Debian)

In which of the above stages does the boot hang?

> I suspect also there is a subset of Case 2 -- The LinkZone had been used to
> interact with a website before being plugged into the PC under test.

Sorry, can't imagine how a modem can be used to "interact with a web 
page" without being connected to a PC.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Status update {Re: PARTIAL DIAGNOSIS of Installation problems}

[Richard Owlett]

On 03/09/2021 07:00 AM, Andrei POPESCU wrote:

On Ma, 09 mar 21, 06:32:33, Richard Owlett wrote:

On 03/08/2021 10:18 AM, songbird wrote:

Richard Owlett wrote:
...

before chasing down this rabbit hole, see if there is an
upgrade for your current kernel on the debian backports
site (for your processor and distribution type).  i just
had an issue with a new device not being recognized and
updated my kernel (for stretch) and it worked fine after
that.



The more I think about my observed symptoms, it would seem logical to be
kernel related.

If the Linkzone is physically connected when PC is turned on, the boot
process will hang until the Linkzone is disconnected.


Please also provide info like the exact stage of the boot process, any
(error) messages on screen, etc.

I've seen this symptom with a laptop before, though it would hang at the
BIOS stage (it was probably trying to boot from it), while you imply
it's later.

Kind regards,
Andrei



I think there are 2 separate states of the Linkzone may have when 
attempting to boot the PC.


1. The Linkzone is off but plugged into the PC.
   Boot appeared normal.

2. The Linkzone is turned on and I have waited for its indicator lights 
to indicate connection to network.
This time the the screen was looping very quickly repeating that it 
was attempting to reset a USB device.


What log should I look in for such an error message?
I know I've seen description of how to interpret the boot process to 
gather information. But where?


I suspect also there is a subset of Case 2 -- The LinkZone had been used 
to interact with a website before being plugged into the PC under test.


I recall having seen the "reset USB device" looping message before but 
sometimes there has just been a blank screen.


HTH

Re: Status update {Re: PARTIAL DIAGNOSIS of Installation problems}

[Joe]

On Tue, 9 Mar 2021 15:00:07 +0200
Andrei POPESCU  wrote:

> On Ma, 09 mar 21, 06:32:33, Richard Owlett wrote:
> > On 03/08/2021 10:18 AM, songbird wrote:  
> > > Richard Owlett wrote:
> > > ...
> > > 
> > > before chasing down this rabbit hole, see if there is an
> > > upgrade for your current kernel on the debian backports
> > > site (for your processor and distribution type).  i just
> > > had an issue with a new device not being recognized and
> > > updated my kernel (for stretch) and it worked fine after
> > > that.
> > >   
> > 
> > The more I think about my observed symptoms, it would seem logical
> > to be kernel related.
> > 
> > If the Linkzone is physically connected when PC is turned on, the
> > boot process will hang until the Linkzone is disconnected.  
> 
> Please also provide info like the exact stage of the boot process,
> any (error) messages on screen, etc.
> 
> I've seen this symptom with a laptop before, though it would hang at
> the BIOS stage (it was probably trying to boot from it), while you
> imply it's later.
> 

Yes, it's fairly common. My desktop (Gigabyte MB, mumble-mumble years
old) does it. Only with some things: it won't try to boot from a
Kindle or mobile phone, but it will try from a USB stick. Depends on
the filesystem/protocol, I suppose. What it won't do is give up after a
time and try the next device, it will just hang permanently.

-- 
Joe

Re: Status update {Re: PARTIAL DIAGNOSIS of Installation problems}

[Joe]

On Tue, 09 Mar 2021 14:57:47 +0200
Anssi Saari  wrote:

> Richard Owlett  writes:
> 
> > The more I think about my observed symptoms, it would seem logical
> > to be kernel related.
> >
> > If the Linkzone is physically connected when PC is turned on, the
> > boot process will hang until the Linkzone is disconnected.  
> 
> I have a guess then. Maybe the Linkzone comes up as a storage device
> and has to be specifically instructed to become a modem. This was a
> common deal with old cellular USB sticks as I recall. A full Linux OS
> usually has something to do this switch while an installer doesn't
> necessarily.
> 
> As a side note, Google tells me the Linkzone uses bog standard
> cdc_ether and rndis_host drivers, same as what USB modems and Android
> phones commonly use.
> 
> 

Usbswitch was the software, and I don't think systemd needs it. A long
time since I used a mobile dongle.

-- 
Joe

Re: Status update {Re: PARTIAL DIAGNOSIS of Installation problems}

[Andrei POPESCU]

On Ma, 09 mar 21, 06:32:33, Richard Owlett wrote:
> On 03/08/2021 10:18 AM, songbird wrote:
> > Richard Owlett wrote:
> > ...
> > 
> > before chasing down this rabbit hole, see if there is an
> > upgrade for your current kernel on the debian backports
> > site (for your processor and distribution type).  i just
> > had an issue with a new device not being recognized and
> > updated my kernel (for stretch) and it worked fine after
> > that.
> > 
> 
> The more I think about my observed symptoms, it would seem logical to be
> kernel related.
> 
> If the Linkzone is physically connected when PC is turned on, the boot
> process will hang until the Linkzone is disconnected.

Please also provide info like the exact stage of the boot process, any 
(error) messages on screen, etc.

I've seen this symptom with a laptop before, though it would hang at the 
BIOS stage (it was probably trying to boot from it), while you imply 
it's later.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Status update {Re: PARTIAL DIAGNOSIS of Installation problems}

[Anssi Saari]

Richard Owlett  writes:

> The more I think about my observed symptoms, it would seem logical to
> be kernel related.
>
> If the Linkzone is physically connected when PC is turned on, the boot
> process will hang until the Linkzone is disconnected.

I have a guess then. Maybe the Linkzone comes up as a storage device and
has to be specifically instructed to become a modem. This was a common
deal with old cellular USB sticks as I recall. A full Linux OS usually
has something to do this switch while an installer doesn't necessarily.

As a side note, Google tells me the Linkzone uses bog standard cdc_ether
and rndis_host drivers, same as what USB modems and Android phones
commonly use.

Re: Status update {Re: PARTIAL DIAGNOSIS of Installation problems}

[Richard Owlett]

On 03/08/2021 10:18 AM, songbird wrote:

Richard Owlett wrote:
...

before chasing down this rabbit hole, see if there is an
upgrade for your current kernel on the debian backports
site (for your processor and distribution type).  i just
had an issue with a new device not being recognized and
updated my kernel (for stretch) and it worked fine after
that.



The more I think about my observed symptoms, it would seem logical to be 
kernel related.


If the Linkzone is physically connected when PC is turned on, the boot 
process will hang until the Linkzone is disconnected.

Re: Status update {Re: PARTIAL DIAGNOSIS of Installation problems}

[songbird]

Richard Owlett wrote:
...
> If it's a kernel issue, I'll just wait for Debian 11. I had essentially 
> tried the 10.8 netinst to get instant gratification of moving from 32 to 
> 64 bits in one day rather than one week.

  certainly understandable.  :)  hope it works well for you!


  songbird

Re: Status update {Re: PARTIAL DIAGNOSIS of Installation problems}

[Richard Owlett]

On 03/08/2021 10:18 AM, songbird wrote:

Richard Owlett wrote:
...

before chasing down this rabbit hole, see if there is an
upgrade for your current kernel on the debian backports
site (for your processor and distribution type).  i just
had an issue with a new device not being recognized and
updated my kernel (for stretch) and it worked fine after
that.



If it's a kernel issue, I'll just wait for Debian 11. I had essentially 
tried the 10.8 netinst to get instant gratification of moving from 32 to 
64 bits in one day rather than one week.


Thanks

Re: Status update {Re: PARTIAL DIAGNOSIS of Installation problems}

[songbird]

Richard Owlett wrote:
...

before chasing down this rabbit hole, see if there is an
upgrade for your current kernel on the debian backports
site (for your processor and distribution type).  i just
had an issue with a new device not being recognized and
updated my kernel (for stretch) and it worked fine after
that.


  songbird

Re: Status update {Re: PARTIAL DIAGNOSIS of Installation problems}

[Andrew M.A. Cater]

On Mon, Mar 08, 2021 at 06:06:17AM -0600, Richard Owlett wrote:
> On 03/03/2021 09:22 AM, Richard Owlett wrote:
> > I've one fine machine running i386 flavor of Debian 9.13 .
> > I've wish to install 64 bit flavor on a second machine.
> > debian-10.8.0-amd64-netinst.iso was successfully downloaded & saved.
> > It was copied to a USB flash drive and installation attempted.
> > Only did minimal install as I could not connect to internet.
> > 
> > To eliminate possibility that second was itself defective I attempted a
> > multi-boot install to the first machine [Dell Latitude E6410].
> > Essentially same result :{
> > 
> > Connection to internet is via a T-Mobile Alcatel Linkzone Hotspot.
> > The WiFi connectivity programmatically disabled (i.e. it is effectively
> > just a modem).
> > It is detected by lsusb as:
> >   Bus 002 Device 008: ID 1bbb:0195 T & A Mobile Phones
> > No non-free driver is needed as none are on the working system.
> > 
> > I attempted to configure the ethernet device with the numeric URL the
> > working machine uses when configuring it. The installer was happy until
> > it tried to connect to a chosen mirror. I tried 3 in the United States
> > and 1 in Canada. None worked.
> > 
> > As I can boot a working Debian on that machine, all installer logs for
> > the failed install are conveniently available.
> > 
> > Also I didn't find anything in
> > https://www.debian.org/releases/stable/amd64/ telling details of how to
> > set up a "ethernet" device.
> > 
> > What do I do now?
> > TIA
> 
> I was able ONCE to use netinst.iso with Alcatel Linkzone to install Debian.
> There seem to be at least two distinct failure modes.
> 
> If the Linkzone has not been used to connect to the web since last power up,
> it *WILL fail repeatably*.
> 
> If it has spent time connected to the web, the install *MAY* succeed.
> Otherwise the error log says the server does not have correct release.
> I will have to do some checking to verify that.
> 
> I hope to prepare a more detailed report later today.
> 
> Thank you.
> 

This ties into the 20 questions email I posed to you to try and narrow down
failure modes:

If your connectivity is intermittent - how do you tell that the Alcatel is
working correctly, you have IP connectivity and connection to the outside 
world?

[In most cases, there's a webpage: if there's an app, how do _you_ access the
app.? ]

If you don't have network connectivity, you won't get to any mirror, obviously.

If the Alcatel is originally designed as a central hot spot to which people
would connect via WiFi - your use of USB to connect is probably an outlying
case that your ISP would have difficulty troubleshooting.

If you could respond to the 20 questions email: that's intended to narrow
down some of the issues :)

All the best, Andy C.


> 
> 
> 
> 

Status update {Re: PARTIAL DIAGNOSIS of Installation problems}

[Richard Owlett]

On 03/03/2021 09:22 AM, Richard Owlett wrote:

I've one fine machine running i386 flavor of Debian 9.13 .
I've wish to install 64 bit flavor on a second machine.
debian-10.8.0-amd64-netinst.iso was successfully downloaded & saved.
It was copied to a USB flash drive and installation attempted.
Only did minimal install as I could not connect to internet.

To eliminate possibility that second was itself defective I attempted a 
multi-boot install to the first machine [Dell Latitude E6410].

Essentially same result :{

Connection to internet is via a T-Mobile Alcatel Linkzone Hotspot.
The WiFi connectivity programmatically disabled (i.e. it is effectively 
just a modem).

It is detected by lsusb as:
  Bus 002 Device 008: ID 1bbb:0195 T & A Mobile Phones
No non-free driver is needed as none are on the working system.

I attempted to configure the ethernet device with the numeric URL the 
working machine uses when configuring it. The installer was happy until 
it tried to connect to a chosen mirror. I tried 3 in the United States 
and 1 in Canada. None worked.


As I can boot a working Debian on that machine, all installer logs for 
the failed install are conveniently available.


Also I didn't find anything in 
https://www.debian.org/releases/stable/amd64/ telling details of how to 
set up a "ethernet" device.


What do I do now?
TIA


I was able ONCE to use netinst.iso with Alcatel Linkzone to install 
Debian. There seem to be at least two distinct failure modes.


If the Linkzone has not been used to connect to the web since last power 
up, it *WILL fail repeatably*.


If it has spent time connected to the web, the install *MAY* succeed.
Otherwise the error log says the server does not have correct release.
I will have to do some checking to verify that.

I hope to prepare a more detailed report later today.

Thank you.

Re: PARTIAL DIAGNOSIS of Installation problems

[Celejar]

On Fri, 5 Mar 2021 21:47:25 +
Joe  wrote:

...

> If it's user-installed non-free firmware for network interfaces, that is
> the state of manufacturing today: we're back to Winmodems and you're
> stuck with it. I have one of the last netbooks to come with an Ethernet
> port. A USB-Ethernet widget is quite useful to have around these days.

To be fair, Winmodems have limited hardware and do much of their work
in software running on the host hardware. Network devices that require
loadable firmware can be quite capable, hardware-wise, and the firmware
runs on the NIC hardware itself. Winmodems therefore often lack Linux
support, since software has to be written for the host, while loadable
firmware doesn't pose any particular technical problem for Linux (aside
from the ideological problem of it being non-free).

Celejar

Re: PARTIAL DIAGNOSIS of Installation problems

[David Wright]

On Mon 01 Feb 2021 at 06:46:40 (-0600), Richard Owlett wrote:
> I have just installed Debian 10.7 to my Lenovo T510 Thinkpad having
> copied debian-10.7.0-amd64-DVD-1.iso to a flash drive [the machine is
> intentionally isolated from the internet].

So you have a 10.7 amd64 DVD available.

On Wed 03 Mar 2021 at 09:22:45 (-0600), Richard Owlett wrote:
> I've one fine machine running i386 flavor of Debian 9.13 .
> I've wish to install 64 bit flavor on a second machine.
> debian-10.8.0-amd64-netinst.iso was successfully downloaded & saved.
> It was copied to a USB flash drive and installation attempted.
> Only did minimal install as I could not connect to internet.

The netinst image is for people with access to the internet.

> Connection to internet is via a T-Mobile Alcatel Linkzone Hotspot.
> The WiFi connectivity programmatically disabled (i.e. it is
> effectively just a modem).
> It is detected by lsusb as:
>  Bus 002 Device 008: ID 1bbb:0195 T & A Mobile Phones
> No non-free driver is needed as none are on the working system.
> 
> I attempted to configure the ethernet device […]

Which ethernet device? You don't have one in your universe.
Now I realise why you wrote ethernet in quotation marks—you're
pretending it's an ethernet connection.

> Also I didn't find anything in
> https://www.debian.org/releases/stable/amd64/ telling details of how
> to set up a "ethernet" device.

Why would there be? If you have a real Ethernet device, bought or
supplied by your real ISP, you just plug a Cat5 cable into it.

. You have a 10.7 amd64 DVD on a stick,

. You have a USB port on the laptop,

. Install it;

. It will work: "install from image of DVD1works."

. Upgrade to 10.8 like everyone else does.

. Then ascertain from *your* own *running* system what it requires
  for connectivity *before* you try to install something from scratch.
  It's called "bootstrapping": at each stage you need a little bit
  of a system that *works* to get you to the next stage.

For someone who doesn't use WiFi, that gizmo looks like a dud.
3/4/5G devices with ethernet do appear to exist, but the ones I've
seen are expensive. They throw in things like a firewall and so on.
But they're not a mass market, so it's hardly surprising they cost.

Cheers,
David.

Re: PARTIAL DIAGNOSIS of Installation problems

[Charles Curley]

On Fri, 5 Mar 2021 21:47:25 +
Joe  wrote:

> In the beginning, the problem was inability to write an .iso to a USB
> stick or to use Google. Since then, things seem to have evolved. There
> are too many posts in this thread to read each one of yours to see
> what is currently the problem, and you have just chosen to rant in
> this post rather than explaining (again, if necessary) exactly what
> the current sticking point is. 

It would help reduce confusion if the OP would, upon solving a problem,
reply indicating that the problem is solved, and how to handle it.

Then the OP should start a new, independent, email thread with the new
problem, if any.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: PARTIAL DIAGNOSIS of Installation problems

[Richard Owlett]

On 03/05/2021 03:47 PM, Joe wrote:

On Fri, 5 Mar 2021 15:12:50 -0600
Richard Owlett  wrote:


Please PLEASE *PLEASE* read what I *ACTUALLY* wrote
!!! *BEFORE* replying to what you WISH I had written !




In the beginning, the problem was inability to write an .iso to a USB
stick or to use Google. Since then, things seem to have evolved. There
are too many posts in this thread to read each one of yours to see what
is currently the problem, and you have just chosen to rant in this post
rather than explaining (again, if necessary) exactly what the current
sticking point is.

If it's user-installed non-free firmware for network interfaces, that is
the state of manufacturing today: we're back to Winmodems and you're
stuck with it. I have one of the last netbooks to come with an Ethernet
port. A USB-Ethernet widget is quite useful to have around these days.




install from image of DVD1works.
install from image of netinst.iso fails.

Re: PARTIAL DIAGNOSIS of Installation problems

[Joe]

On Fri, 5 Mar 2021 15:12:50 -0600
Richard Owlett  wrote:

> Please PLEASE *PLEASE* read what I *ACTUALLY* wrote
> !!! *BEFORE* replying to what you WISH I had written !
> 
> 

In the beginning, the problem was inability to write an .iso to a USB
stick or to use Google. Since then, things seem to have evolved. There
are too many posts in this thread to read each one of yours to see what
is currently the problem, and you have just chosen to rant in this post
rather than explaining (again, if necessary) exactly what the current
sticking point is. 

If it's user-installed non-free firmware for network interfaces, that is
the state of manufacturing today: we're back to Winmodems and you're
stuck with it. I have one of the last netbooks to come with an Ethernet
port. A USB-Ethernet widget is quite useful to have around these days.

-- 
Joe

Re: PARTIAL DIAGNOSIS of Installation problems

[Richard Owlett]

Please PLEASE *PLEASE* read what I *ACTUALLY* wrote
!!! *BEFORE* replying to what you WISH I had written !

Re: PARTIAL DIAGNOSIS of Installation problems

[David Christensen]

On 3/5/21 4:09 AM, Richard Owlett wrote:

On 03/04/2021 04:46 PM, David Christensen wrote:



2. I _actively_ abhor activating *any* WiFi device. [long OT story]



My system currently has [from image of DVD1]:
   1. Debian 10.0 with minimum default configuration of MATE.



That is a security risk.  Update it.  If you succeed, then you do not 
need to install 10.8.




   2. Debian 9.13 with MATE with lots of extras.
Neither has any non-free drivers and both connect readily to internet.



How does your computer connect to the Internet?


Attempting to install Debian 10.8.0 from image of netinst.iso downloaded 
after following default link from Debian homepage. 



Ignore the giant "Download" button on the Debian home page and go to 
this page:


https://www.debian.org/CD/

ignore this message:

"If you simply want to install Debian and have an Internet
connection on the target computer please consider the Network
Install media which is a smaller download."


Download a complete installer.  I use this:


https://cdimage.debian.org/debian-cd/current/amd64/jigdo-cd/debian-10.8.0-amd64-xfce-CD-1.jigdo


The apparent failure 
point is on the screen offering automatic configuration using DHCP.



You need to load the Wi-Fi packages and get your Wi-Fi interface working 
before that point.



Are you following the instructions?

https://www.debian.org/releases/stable/amd64/ch02s02.en.html

https://www.debian.org/releases/stable/amd64/ch06s04.en.html


Have you tried "Expert Mode"?


With a complete installer, if you can install the Wi-Fi packages during 
installation, fine.  If not, do the installation and figure out the 
Wi-Fi later.



David

Re: [OFFTOPIC] Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems]

[Gene Heskett]

On Friday 05 March 2021 03:14:51 to...@tuxteam.de wrote:

> On Fri, Mar 05, 2021 at 01:33:14AM -0500, Stefan Monnier wrote:
> > > AIUI compilers have been studied so extensively that their
> > > production is largely automated.
> >
> > Oh, no.  There are some parts we know how to automate, but by and
> > large it's all hand written code.
> >
> :-)
>
> https://m.xkcd.com/224/
>
Thanks for my morning chuckle, Tomas. I needed that, badly.

> Cheers
>  - t


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: PARTIAL DIAGNOSIS of Installation problems

[Richard Owlett]

On 03/04/2021 04:46 PM, David Christensen wrote:

On 3/4/21 4:27 AM, Richard Owlett wrote:


What I do now is make yet another attempt to convey my problem.

My universe consists of:
   1. myself.
   2. a laptop onto which I wish to install Debian using a netinst.iso .
   3. an Alcatel Linkzone sold me by T-Mobile, my ISP.
  T-Mobile erroneously ASSUMES that *all*customers will use it as a
  WiFi Hotspot to create a LAN of up to 15 devices.
  I, however, disable the WiFi as that function has *NO* value to me.
   4. Debian, absent *ANY* non-free drivers, which is slightly schizoid
  in that:
  a. it will happily connect to internet if it was installed from an
 image of DVD1.
  b. its installer which assumes one has *exactly* 2 ways to connect
WiFi
"ethernet" N.B. the quotes and use of lower case
   5. the internet which has all the privacy of a party-linefrom over
  three score and ten in the past.


I will assume you have this device:


https://www.alcatelmobile.com/product/mobile-broadband/mobile-wifi/linkzone-cat4-mobile-wi-fi/#spec 



That looks like what I have.




I will assume your laptop has a Wi-Fi adapter.


It does. {With two BUTS ;}
1. I don't know if it id defective or not.
2. I _actively_ abhor activating *any* WiFi device. [long OT story]




Identify which Debian package(s) are required for your Wi-Fi adapter 
(firmware, utilities, whatever).  Download the packages and put them on 
a USB flash drive.



Boot the Debian installer.  Insert the USB flash drive with the Wi-Fi 
packages when needed.  Install the Wi-Fi packages.  Proceed with the 
Debian installation.




That would be a "workaround" but not a diagnosis/solution.
I'm working with a multi-boot system to make all environments as 
consistent as possible.


My system currently has [from image of DVD1]:
  1. Debian 10.0 with minimum default configuration of MATE.
  2. Debian 9.13 with MATE with lots of extras.
Neither has any non-free drivers and both connect readily to internet.

Attempting to install Debian 10.8.0 from image of netinst.iso downloaded 
after following default link from Debian homepage. The apparent failure 
point is on the screen offering automatic configuration using DHCP.

Re: [OFFTOPIC] Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems]

[tomas]

On Fri, Mar 05, 2021 at 01:33:14AM -0500, Stefan Monnier wrote:
> > AIUI compilers have been studied so extensively that their production is
> > largely automated.
> 
> Oh, no.  There are some parts we know how to automate, but by and large
> it's all hand written code.

:-)

https://m.xkcd.com/224/

Cheers
 - t


signature.asc
Description: Digital signature

Re: [OFFTOPIC] Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems]

[Stefan Monnier]

> AIUI compilers have been studied so extensively that their production is
> largely automated.

Oh, no.  There are some parts we know how to automate, but by and large
it's all hand written code.

> Create an EBNF specification, feed it through a tool
> chain (lex, yacc, cc, as, ld, etc.), and you end up with a compiler.

The EBNF specification only gives you the syntax of the source language.
It's barely sufficient for a pretty printer, but lacks all the
information about typing rules and dynamic semantics of the source
language, as well as any information about the syntax and semantics of
the target language, and doesn't say anything about to optimize the
code either.

The part you can automate with lex/yacc and friends is a tiny fraction
of a compiler, except for very naive toy compilers.

> The process is known and the results are predictable; especially with
> standards-based languages such as C.  So, a skilled attacker will know
> what you're doing, how you are doing it, and may be able to produce a
> 'cA' that infects both 'A' and 'T'.

That is a risk, indeed.

> If you are going to produce source code for a trusted compiler 'T', then you
> should also produce an executable 'cT'.

That could be significantly harder.

> AIUI this can be done by writing a simplified compiler in some other
> language 'a',

Indeed, actually your trusted compiler `T` doesn't need to be compiled
with `cA` (nor written in the same source language), it just needs to be
used somehow to compile `A` to `cA2` so it can be compared to `cA` to
see if there's a backdoor.


Stefan

Re: [OFFTOPIC] Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems]

[David Christensen]

On 3/4/21 9:28 PM, David Christensen wrote:

(One more step of 'cT = cT(a)' may be required


Correction:  cT = cT(T)


David

Re: [OFFTOPIC] Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems]

[David Christensen]

On 3/4/21 6:50 PM, Stefan Monnier wrote:

The abstract states:

"In the DDC technique, source code is compiled twice: once with a 
second (trusted) compiler (using the source code of the compiler’s 
parent), and then the compiler source code is compiled using the 
result of the first compilation. If the result is bit-for-bit 
identical with the untrusted executable, then the source code 
accurately represents the executable."



I find the above to be unclear:


Of course, it's an abstract.  You can read the paper for more
details. Basically:

Take an existing untrusted compiler whose source code is A and binary
is cA.  You check that:

cA == cA(A)

if it's not the case (or if you don't have access to the source code
A), the DDC technique can't be used.  If it is the case, you have
just checked that `A` is indeed the source code for `cA`.



You have checked that 'cA' can reproduce itself given 'A' as input. 
This is the key feature of the TT attack -- the machine code executable 
'cA' contains a backdoor, but the source code 'A' does not.



The backdoor source code was removed from 'A' once the backdoor machine 
code injection was working in 'cA'.  The backdoor machine code injection 
in 'cA' is what perpetuates the TT attack whenever 'cA' is recompiled 
from 'A'.




Then take a trusted compiler whose source code is T. Now compile it
with `cA`:

cT = cA(T)

and then use this new compiler binary `cT` to compile `A` a second
time:

cA2 = cT(A)

finally compare `cA` and `cA2`. If they're bit-for-bit identical,
then you're good: `cA` doesn't seem to have any hidden trojan horse.


You need to not only trust that [T] does what you think it does, but 
also that any attacker who may have infected `cA` hasn't seen [T]

and can't have guessed enough of its content to be able to properly
infect `cT`.


Thanks for the explanation.


AIUI compilers have been studied so extensively that their production is
largely automated.  Create an EBNF specification, feed it through a tool
chain (lex, yacc, cc, as, ld, etc.), and you end up with a compiler.
The process is known and the results are predictable; especially with
standards-based languages such as C.  So, a skilled attacker will know
what you're doing, how you are doing it, and may be able to produce a
'cA' that infects both 'A' and 'T'.


If you are going to produce source code for a trusted compiler 'T', then 
you should also produce an executable 'cT'.  AIUI this can be done by 
writing a simplified compiler in some other language 'a', using that to 
create an intermediate compiler 'aT = a(T)', and using that to produce 
the compiler 'cT = aT(T)'.  (One more step of 'cT = cT(a)' may be 
required to obtain a fixed point binary.)  Now you can compare 'cA' to 
'cT(A)' and see the back door directly.



David

[OFFTOPIC] Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems]

[Stefan Monnier]

> The abstract states:
>
> "In the DDC technique, source code is compiled twice: once with a
> second (trusted) compiler (using the source code of the compiler’s
> parent), and then the compiler source code is compiled using the
> result of the first compilation. If the result is bit-for-bit
> identical with the untrusted executable, then the source code
> accurately represents the executable."
>
>
> I find the above to be unclear:

Of course, it's an abstract.  You can read the paper for more details.
Basically:

Take an existing untrusted compiler whose source code is A and binary is
cA.  You check that:

cA == cA(A)

if it's not the case (or if you don't have access to the source code A),
the DDC technique can't be used.  If it is the case, you have just
checked that `A` is indeed the source code for `cA`.

Then take a trusted compiler whose source code is T.
Now compile it with `cA`:

cT = cA(T)

and then use this new compiler binary `cT` to compile `A` a second time:

cA2 = cT(A)

finally compare `cA` and `cA2`.
If they're bit-for-bit identical, then you're good: `cA` doesn't seem to
have any hidden trojan horse.

If they're not, then either cA is compromised, or maybe it's simply that
the compilers A and T don't agree sufficiently on the source language
in which they're both written.

> 1.  What source code is compiled twice?

The source code `A` of the untrusted compiler.

> 2.  Where do I get the second (trusted) compiler?

You write it yourself by hand.  You also have to make sure that it
matches the semantics of `A` sufficiently to avoid false negatives.
You need to not only trust that it does what you think it does, but also
that any attacker who may have infected `cA` hasn't seen that code and
can't have guessed enough of its content to be able to properly infect
`cT`.

> 7.  What if the compiler, by design, does not produce identical output for
>identical input?

Then you can't use that technique and you're left wondering if it may
have a hidden self-perpetuating backdoor.


Stefan

Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems]

[Joe]

On Thu, 4 Mar 2021 23:34:25 +0100
 wrote:

  
> 
> Yes, but... letting your compiler plant bugs into someone else's
> software to phone back to *you*... chutzpah. Had to be Microsoft.
> 
>

Not necessarily, nearly all writers of Windows software believe that
they own your computer while their software is running on it. It's a
particular mindset, which seems to have propagated to Android. I don't
know about iOS.

It's one of the main reasons I use Linux where possible. Where not
possible, I try to use Windows versions of OS Linux software e.g.
LibreOffice, or written by well-known people like Simon Tatham.

-- 
Joe

Re: PARTIAL DIAGNOSIS of Installation problems

[David Christensen]

On 3/4/21 4:27 AM, Richard Owlett wrote:


What I do now is make yet another attempt to convey my problem.

My universe consists of:
   1. myself.
   2. a laptop onto which I wish to install Debian using a netinst.iso .
   3. an Alcatel Linkzone sold me by T-Mobile, my ISP.
  T-Mobile erroneously ASSUMES that *all* customers will use it as a
  WiFi Hotspot to create a LAN of up to 15 devices.
  I, however, disable the WiFi as that function has *NO* value to me.
   4. Debian, absent *ANY* non-free drivers, which is slightly schizoid
  in that:
  a. it will happily connect to internet if it was installed from an
     image of DVD1.
  b. its installer which assumes one has *exactly* 2 ways to connect
     WiFi
     "ethernet" N.B. the quotes and use of lower case
   5. the internet which has all the privacy of a party-line from over
  three score and ten in the past.


I will assume you have this device:


https://www.alcatelmobile.com/product/mobile-broadband/mobile-wifi/linkzone-cat4-mobile-wi-fi/#spec


I will assume your laptop has a Wi-Fi adapter.


Identify which Debian package(s) are required for your Wi-Fi adapter 
(firmware, utilities, whatever).  Download the packages and put them on 
a USB flash drive.



Boot the Debian installer.  Insert the USB flash drive with the Wi-Fi 
packages when needed.  Install the Wi-Fi packages.  Proceed with the 
Debian installation.



David

Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems]

[tomas]

On Thu, Mar 04, 2021 at 05:18:38PM -0500, Stefan Monnier wrote:
> > The part that I find more interesting is the "emergent evil" thing.
> > Somehow the techies found that it is OK to do that and they did,
> > in the best of their intentions.
> 
> I'm not surprised: it's quite common to want to get some kind of
> information about how your program performs (i.e. things like profiling
> your code), and it's often hard to get a good view of that with
> artificial local tests, so there's a strong motivation to try and do
> that profiling on "in real life".

Yes, but... letting your compiler plant bugs into someone else's
software to phone back to *you*... chutzpah. Had to be Microsoft.

> Emacs's tradition is to be quite conservative when it comes to
> initiating network connections, but nowadays many if not most
> applications have some kind of "call home" functionality (e.g. to check
> if there's a more recent release).  It's absurdly considered normal.

Emacs hasn't the kind of culture which would approve of something
like that willy-nilly. That's what I appreciate about it.

Cheers
 - t


signature.asc
Description: Digital signature

Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems]

[David Christensen]

On 3/4/21 12:43 AM, to...@tuxteam.de wrote:


Read David A. Wheeler's work [1] and put yourself in the 2010s :-)


> [1] https://dwheeler.com/trusting-trust/

The abstract states:

"In the DDC technique, source code is compiled twice: once with a
second (trusted) compiler (using the source code of the compiler’s
parent), and then the compiler source code is compiled using the
result of the first compilation. If the result is bit-for-bit
identical with the untrusted executable, then the source code
accurately represents the executable."


I find the above to be unclear:

1.  What source code is compiled twice?

2.  Where do I get the second (trusted) compiler?

3.  How do I compile using the source code of the compiler's parent?

5.  Is the compiler source code the same as, or different from, the 
source code of the compiler's parent?


6.  What result and what untrusted executable are compared bit-for-bit?

7.  What if the compiler, by design, does not produce identical output 
for identical input?


8.  Where do I get a trusted computer to do all of the above?



Back to the topic: I do trust my ISP significantly less than I do
OpenWRT. Therefore there is something between their provided router
and my home network.


Layering is a traditional defensive strategy.


David

Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems]

[Stefan Monnier]

> The part that I find more interesting is the "emergent evil" thing.
> Somehow the techies found that it is OK to do that and they did,
> in the best of their intentions.

I'm not surprised: it's quite common to want to get some kind of
information about how your program performs (i.e. things like profiling
your code), and it's often hard to get a good view of that with
artificial local tests, so there's a strong motivation to try and do
that profiling on "in real life".

Emacs's tradition is to be quite conservative when it comes to
initiating network connections, but nowadays many if not most
applications have some kind of "call home" functionality (e.g. to check
if there's a more recent release).  It's absurdly considered normal.


Stefan

Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems]

[Celejar]

On Thu, 4 Mar 2021 19:05:38 +0100
to...@tuxteam.de wrote:

> On Thu, Mar 04, 2021 at 11:16:25AM -0500, Celejar wrote:

...

> > I know I can't avoid the risk
> > entirely, but this is one of the reasons I try hard to limit my use of
> > software to stuff in the repos. I understand it's no magic bullet
> > against this type of thing, but in my (not very informed) judgment, it's
> > less likely to happen to stuff that Debian is vetting. I.e., I'm hoping
> > that all those hoops that Debian makes packages jump through, which
> > prevent stuff I do want from entering the repos, will work here in my
> > favor ;)
> 
> That's my approach, too; but I realise that trust is, at the bottom,
> a social thing. Technology can only be a tool in this.
> 
> The "classical" distro way is becoming more and more difficult; for
> "monsters" like Chrome, the distribution can't vet everything, and as
> software becomes more and more entangled (with version dependencies
> on the newest micro-version), people resort more and more to docker
> images, flatpaks and what have you.

Indeed. Recent example: I wanted to learn Kotlin and try some simple
Android development. Neither IntelliJ IDEA nor Android Studio are in
the repos, so I had to install them from upstream's tarballs and hope
for the best. I suppose I could have been more principled and installed
them to VMs or containers - maybe I should still reconsider and do that.

Celejar

Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems]

[tomas]

On Thu, Mar 04, 2021 at 11:16:25AM -0500, Celejar wrote:

[...]

> > - Sometime 2017 [1], Microsoft put out a version of Visual Studio
> >   which baked "phone home" functionality into its compiled "products".

[...]

> >   I call this pattern "Emergent Evil".
> 
> Outrageous, certainly - this sort of thing is one of the reasons I
> use linux and avoid Microsoft products to the extent I find practical.
> But I don't consider this a "build-chain attack."

Well, it's the compiler injecting unexpected functionality into the
compilee -- i.e. half to three quarters Thompson.

The part that I find more interesting is the "emergent evil" thing.
Somehow the techies found that it is OK to do that and they did,
in the best of their intentions. They are not the evil ones. I don't
think some manager up the ladder told them to do it. It must be the
whole corporate culture, i.e. some kind of emergent behaviour.

At the end, trust is a social thing. I trust Debian, because.

> > - NPM buildchain attacks [...]

> Agreed - this sort of thing is scary.

the one example I provided is special, because it was extremely
refined: someone taking over an orphaned npm package,
and laser-targeting one product's build chain.

> I know I can't avoid the risk
> entirely, but this is one of the reasons I try hard to limit my use of
> software to stuff in the repos. I understand it's no magic bullet
> against this type of thing, but in my (not very informed) judgment, it's
> less likely to happen to stuff that Debian is vetting. I.e., I'm hoping
> that all those hoops that Debian makes packages jump through, which
> prevent stuff I do want from entering the repos, will work here in my
> favor ;)

That's my approach, too; but I realise that trust is, at the bottom,
a social thing. Technology can only be a tool in this.

The "classical" distro way is becoming more and more difficult; for
"monsters" like Chrome, the distribution can't vet everything, and as
software becomes more and more entangled (with version dependencies
on the newest micro-version), people resort more and more to docker
images, flatpaks and what have you.

Cheers
 - t


signature.asc
Description: Digital signature

Re: PARTIAL DIAGNOSIS of Installation problems

[David Wright]

On Thu 04 Mar 2021 at 06:27:30 (-0600), Richard Owlett wrote:
> On 03/03/2021 09:22 AM, Richard Owlett wrote:
> > I've one fine machine running i386 flavor of Debian 9.13 .
> > I've wish to install 64 bit flavor on a second machine.
> > debian-10.8.0-amd64-netinst.iso was successfully downloaded & saved.
> > It was copied to a USB flash drive and installation attempted.
> > Only did minimal install as I could not connect to internet.
> > 
> > To eliminate possibility that second was itself defective I
> > attempted a multi-boot install to the first machine [Dell Latitude
> > E6410].
> > Essentially same result :{
> > 
> > Connection to internet is via a T-Mobile Alcatel Linkzone Hotspot.
> > The WiFi connectivity programmatically disabled (i.e. it is
> > effectively just a modem).
> > It is detected by lsusb as:
> >   Bus 002 Device 008: ID 1bbb:0195 T & A Mobile Phones
> > No non-free driver is needed as none are on the working system.
> > 
> > I attempted to configure the ethernet device with the numeric URL
> > the working machine uses when configuring it. The installer was
> > happy until it tried to connect to a chosen mirror. I tried 3 in
> > the United States and 1 in Canada. None worked.
> > 
> > As I can boot a working Debian on that machine, all installer logs
> > for the failed install are conveniently available.
> > 
> > Also I didn't find anything in
> > https://www.debian.org/releases/stable/amd64/ telling details of
> > how to set up a "ethernet" device.
> > 
> > What do I do now?
> > TIA
> 
> What I do now is make yet another attempt to convey my problem.
> 
> My universe consists of:
>   1. myself.

That could be a problem.

>   2. a laptop onto which I wish to install Debian using a netinst.iso .
>   3. an Alcatel Linkzone sold me by T-Mobile, my ISP.
>  T-Mobile erroneously ASSUMES that *all* customers will use it as a
>  WiFi Hotspot to create a LAN of up to 15 devices.
>  I, however, disable the WiFi as that function has *NO* value to me.

You say T-Mobile is your ISP. What equipment do they offer or provide
as part of that service?

When I look them up, I see just a cylindrical device providing WiFi,
Ethernet × 2, and telephone jack, at $50 pm with no data caps.
Or is that wrong?

>   4. Debian, absent *ANY* non-free drivers, which is slightly schizoid
>  in that:
>  a. it will happily connect to internet if it was installed from an
> image of DVD1.

So make a nonce installation on the laptop, and use the tools in that
to discover what's absent¹ from the netinst ISO. Manually download
whatever's needed, and then install your netinst over the top.

>  b. its installer which assumes one has *exactly* 2 ways to connect
> WiFi
> "ethernet" N.B. the quotes and use of lower case

I have no idea what special meaning your use of Ethernet is meant to convey.

>   5. the internet which has all the privacy of a party-line from over
>  three score and ten in the past.

You wrote earlier "I'm not aware of any germane issue with my internet
service, nor with my ISP". As I see it, there are several:

1. You appear to have no Ethernet connection at all, but you're
   unwilling to use the connectivity they provide.

2. Your data cap precludes downloading another DVD1 for the new
   architecture.

3. Your new attempt to specify "the problem" adds the words "which has
   all the privacy of a party-line from over [70 years ago]". Does
   this indicate you should purchase a DVD set for the new architecture?

So I suppose I finally have to ask *the* question—do you actually
have an internet service, or are you just using a data allocation
that comes with a mobile phone service?

¹ I previously suggested "firmware", but it seems, rather, that you
  lack the drivers themselves.

Cheers,
David.

OT: Bathroom scales (was: Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems])

[rhkramer]

Hey, bathroom scales are something (I think) I am qualified to talk about, at 
least from the POV of a user ;-)

On Thursday, March 04, 2021 10:05:29 AM Joe wrote:
> On a rather smaller scale, my electronic bathroom scale has a feature
> whereby if a person gets back onto the scale within thirty seconds of
> the display blanking, *exactly* the same weight is reported. 

Mine seems a little different -- it seems even if I weigh myself the next week 
and my weight is within a few (for some value of few) tenths of the previous 
weight, my previous weight is reported.  To get a valid weight, I have to do 
something like hold something heavy (a few pounds) so my weight is 
significantly different, wait until that weight is "registered", then set the 
weight down and re-weigh myself.

> If more
> than thirty seconds elapse, then a slightly different weight will often
> result, as expected. I would assume that if the weight of the repeat
> user was more than a certain amount different from the first user, a
> second genuine weight would be shown. 

As described above, this part works on my scale.

> I *know* this a deliberate
> feature of the software used, I don't have to see the code, and I don't
> have to be told whether it is a bug accidentally introduced. But even
> the manufacturing company's MD/CEO may not know about it.

I agree  ;-)

Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems]

[Celejar]

On Thu, 4 Mar 2021 16:14:08 +0100
to...@tuxteam.de wrote:

> On Thu, Mar 04, 2021 at 09:21:46AM -0500, Celejar wrote:
> > On Thu, 4 Mar 2021 14:17:59 +0100
> >  wrote:
> > 
> > > On Thu, Mar 04, 2021 at 08:10:45AM -0500, Celejar wrote:
> > > > On Thu, 4 Mar 2021 09:41:13 +
> > > > Joe  wrote:
> > > > 
> > > > ...
> > > > 
> > > > > Undoubtedly. But there is also no doubt that gcc and every other
> > > > > serious compiler in the West has been compromised. Why would they 
> > > > > *not*
> > > > > be?
> > > > 
> > > > Do you have any evidence for this, or is it just your assumption,
> > > > because "why would they not be?"
> > > 
> > > You mean GCC specifically or some examples of build chain attacks
> > > in general? Because in the second case there are some nice specimens
> > > out there.
> > 
> > I'm interested in anything, although my comment was focused
> > particularly on things as critical, fundamental, and ubiquitous as GCC
> > and "every other serious compiler."
> 
> Two off the top of my head
> 
> - Sometime 2017 [1], Microsoft put out a version of Visual Studio
>   which baked "phone home" functionality into its compiled "products".
>   Make no mistake: it phoned Microsoft. Imagine you compile an
>   application for your customer, and this app phones... Microsoft.
> 
>   Some hilarity ensued. They said "oh, sorry. It wasn't with bad
>   intentions" and reverted it.
> 
>   I call this pattern "Emergent Evil".

Outrageous, certainly - this sort of thing is one of the reasons I
use linux and avoid Microsoft products to the extent I find practical.
But I don't consider this a "build-chain attack."

> - NPM buildchain attacks are more and more frequent. Just publish
>   a package out there and wait until someone takes the bait.
>   An especially nice one was the event-stream [2] episode, where
>   the malicious code only injected malicious code (yes, really)
>   when it noticed that it was "in" the right build environment.
>   Nice read. I'm sure this ain't the only one in this context.

Agreed - this sort of thing is scary. I know I can't avoid the risk
entirely, but this is one of the reasons I try hard to limit my use of
software to stuff in the repos. I understand it's no magic bullet
against this type of thing, but in my (not very informed) judgment, it's
less likely to happen to stuff that Debian is vetting. I.e., I'm hoping
that all those hoops that Debian makes packages jump through, which
prevent stuff I do want from entering the repos, will work here in my
favor ;)

> Note that I'm no specialist. Otherwise the top of my head would
> be heavier ;-)
> 
> Cheers
> 
> [1] 
> https://www.reddit.com/r/cpp/comments/4ibauu/visual_studio_adding_telemetry_function_calls_to/
> [2] https://lwn.net/Articles/773121/

Celejar

Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems]

[Celejar]

On Thu, 4 Mar 2021 15:05:29 +
Joe  wrote:

> On Thu, 4 Mar 2021 08:10:45 -0500
> Celejar  wrote:
> 
> > On Thu, 4 Mar 2021 09:41:13 +
> > Joe  wrote:

...

> > > Indeed. The new heartbeat/data return function in OpenSSL, itself
> > > the core of much Open Source security, was suggested by the
> > > programmer himself, and the resulting code was audited by *one*
> > > other person before approval and distribution. What could possibly
> > > go wrong?  
> > 
> > The problem I have with your claim is that AFAIK none of the
> > ostensible compromises you assume exist have ever been discovered. I
> > know there's speculation that this was a backdoor:
> > 
> > https://www.debian.org/security/2008/dsa-1571
> > https://freedom-to-tinker.com/2013/09/20/software-transparency-debian-openssl-bug/
> > 
> > but that's never been established, and my understanding is that it's
> > considered unlikely.
> 
> It was certainly a backdoor for those who knew about it, whether it was
> accidental or deliberate is not known, as with Heartbleed.
> 
> In both cases as I understand it, the error was clear in the source
> code, and does not require the existence of a compromised toolchain.
> But I don't believe that someone building, say, Linux From Scratch will
> end up with a guaranteed backdoor-free system.

Well, yes, if you redefine "backdoor" to mean "a vulnerability that
enables outsiders to access a system," then I agree that realistically,
there will never be any "guaranteed backdoor-free system," at least not
with current technology.

> > Human beings being what they are, is it really plausible that no one
> > involved has ever let the cat out of the bag? Are the TLAs really that
> > good at what they do? I mean, we have Snowden ...
> >
> There was a maximum of two people involved in Heartbleed, apart from
> any hypothetical intelligence paymasters. It really would be possible
> for a bit of clandestine computer code to be known only to one or two
> people in exactly the right position in an organisation. The VW
> emissions fix would have been known to only a couple of people, and was
> discovered empirically, not reported by a whistleblower.

A fair point. But I still don't find it that plausible that this kind
of thing would be widespread with barely any hint of it ever coming to
light.

Celejar

Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems]

[tomas]

On Thu, Mar 04, 2021 at 09:21:46AM -0500, Celejar wrote:
> On Thu, 4 Mar 2021 14:17:59 +0100
>  wrote:
> 
> > On Thu, Mar 04, 2021 at 08:10:45AM -0500, Celejar wrote:
> > > On Thu, 4 Mar 2021 09:41:13 +
> > > Joe  wrote:
> > > 
> > > ...
> > > 
> > > > Undoubtedly. But there is also no doubt that gcc and every other
> > > > serious compiler in the West has been compromised. Why would they *not*
> > > > be?
> > > 
> > > Do you have any evidence for this, or is it just your assumption,
> > > because "why would they not be?"
> > 
> > You mean GCC specifically or some examples of build chain attacks
> > in general? Because in the second case there are some nice specimens
> > out there.
> 
> I'm interested in anything, although my comment was focused
> particularly on things as critical, fundamental, and ubiquitous as GCC
> and "every other serious compiler."

Two off the top of my head

- Sometime 2017 [1], Microsoft put out a version of Visual Studio
  which baked "phone home" functionality into its compiled "products".
  Make no mistake: it phoned Microsoft. Imagine you compile an
  application for your customer, and this app phones... Microsoft.

  Some hilarity ensued. They said "oh, sorry. It wasn't with bad
  intentions" and reverted it.

  I call this pattern "Emergent Evil".

- NPM buildchain attacks are more and more frequent. Just publish
  a package out there and wait until someone takes the bait.
  An especially nice one was the event-stream [2] episode, where
  the malicious code only injected malicious code (yes, really)
  when it noticed that it was "in" the right build environment.
  Nice read. I'm sure this ain't the only one in this context.

Note that I'm no specialist. Otherwise the top of my head would
be heavier ;-)

Cheers

[1] 
https://www.reddit.com/r/cpp/comments/4ibauu/visual_studio_adding_telemetry_function_calls_to/
[2] https://lwn.net/Articles/773121/

 - t


signature.asc
Description: Digital signature

Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems]

[Joe]

On Thu, 4 Mar 2021 08:10:45 -0500
Celejar  wrote:

> On Thu, 4 Mar 2021 09:41:13 +
> Joe  wrote:
> 
> ...
> 
> > Undoubtedly. But there is also no doubt that gcc and every other
> > serious compiler in the West has been compromised. Why would they
> > *not* be?  
> 
> Do you have any evidence for this, or is it just your assumption,
> because "why would they not be?"

No, of course not. I simply don't think the West's intelligence
services would tolerate the existence of computer equipment without
backdoors, in the same way that I don't think the unprecedented product
market share of Windows would have been permitted without some sort of
quid pro quo.

Much has been made of potential backdoors in Huawei network equipment.
My belief is that all Western network equipment is likely to have such
backdoors, though probably not reporting to the Chinese government. I
don't really believe that iptables/nftables would keep out the CIA, for
example.
> 
> > > The one aspect missing is, though, the "social" aspect: the
> > > software endeavour has become so devilishly complex that the idea
> > > of One Person (TM) checking everything down to some hypothetical
> > > "Trust Roots" is... theoretical, to state it politely. You gotta
> > > delegate some trust (well, most of it, actually).  
> > 
> > Indeed. The new heartbeat/data return function in OpenSSL, itself
> > the core of much Open Source security, was suggested by the
> > programmer himself, and the resulting code was audited by *one*
> > other person before approval and distribution. What could possibly
> > go wrong?  
> 
> The problem I have with your claim is that AFAIK none of the
> ostensible compromises you assume exist have ever been discovered. I
> know there's speculation that this was a backdoor:
> 
> https://www.debian.org/security/2008/dsa-1571
> https://freedom-to-tinker.com/2013/09/20/software-transparency-debian-openssl-bug/
> 
> but that's never been established, and my understanding is that it's
> considered unlikely.

It was certainly a backdoor for those who knew about it, whether it was
accidental or deliberate is not known, as with Heartbleed.

In both cases as I understand it, the error was clear in the source
code, and does not require the existence of a compromised toolchain.
But I don't believe that someone building, say, Linux From Scratch will
end up with a guaranteed backdoor-free system.
> 
> 
> Human beings being what they are, is it really plausible that no one
> involved has ever let the cat out of the bag? Are the TLAs really that
> good at what they do? I mean, we have Snowden ...
>
There was a maximum of two people involved in Heartbleed, apart from
any hypothetical intelligence paymasters. It really would be possible
for a bit of clandestine computer code to be known only to one or two
people in exactly the right position in an organisation. The VW
emissions fix would have been known to only a couple of people, and was
discovered empirically, not reported by a whistleblower.

On a rather smaller scale, my electronic bathroom scale has a feature
whereby if a person gets back onto the scale within thirty seconds of
the display blanking, *exactly* the same weight is reported. If more
than thirty seconds elapse, then a slightly different weight will often
result, as expected. I would assume that if the weight of the repeat
user was more than a certain amount different from the first user, a
second genuine weight would be shown. I *know* this a deliberate
feature of the software used, I don't have to see the code, and I don't
have to be told whether it is a bug accidentally introduced. But even
the manufacturing company's MD/CEO may not know about it.

-- 
Joe

Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems]

[Celejar]

[Please don't top post.]

On Thu, 04 Mar 2021 13:39:56 +
Leandro neto  wrote:

> I discover it on October 2019 nobody listen to me

Are you able to document it - can you point to a publicly available
version of GCC (or whatever software you're talking about) that
contained a backdoor?

> Assunto: Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems]
> De: to...@tuxteam.de
> Enviado em: 4 de março de 2021 10:18
> Para: cele...@gmail.com
> Cópia: debian-user@lists.debian.org
> 
> 
> 
> On Thu, Mar 04, 2021 at 08:10:45AM -0500, Celejar wrote: > On Thu, 4 Mar 2021 
> 09:41:13 + > Joe wrote: > > ... > > > Undoubtedly. But there is also no 
> doubt that gcc and every other > > serious compiler in the West has been 
> compromised. Why would they *not* > > be? > > Do you have any evidence for 
> this, or is it just your assumption, > because "why would they not be?" You 
> mean GCC specifically or some examples of build chain attacks in general? 
> Because in the second case there are some nice specimens out there. Cheers - t

Celejar

Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems]

[Celejar]

On Thu, 4 Mar 2021 14:17:59 +0100
 wrote:

> On Thu, Mar 04, 2021 at 08:10:45AM -0500, Celejar wrote:
> > On Thu, 4 Mar 2021 09:41:13 +
> > Joe  wrote:
> > 
> > ...
> > 
> > > Undoubtedly. But there is also no doubt that gcc and every other
> > > serious compiler in the West has been compromised. Why would they *not*
> > > be?
> > 
> > Do you have any evidence for this, or is it just your assumption,
> > because "why would they not be?"
> 
> You mean GCC specifically or some examples of build chain attacks
> in general? Because in the second case there are some nice specimens
> out there.

I'm interested in anything, although my comment was focused
particularly on things as critical, fundamental, and ubiquitous as GCC
and "every other serious compiler."

Celejar

Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems]

[Leandro neto]

 

 I discover it on October 2019 nobody listen to me
 
 Enviado via UOL Mail


 
 
  
  
  Assunto: Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems]
  
  De: to...@tuxteam.de
  
  Enviado em: 4 de março de 2021 10:18
  
  Para: cele...@gmail.com
  
  Cópia: debian-user@lists.debian.org
  
  
  
  
  
   
 On Thu, Mar 04, 2021 at 08:10:45AM -0500, Celejar wrote: > On Thu, 4 Mar 2021 09:41:13 + > Joe wrote: > > ... > > > Undoubtedly. But there is also no doubt that gcc and every other > > serious compiler in the West has been compromised. Why would they *not* > > be? > > Do you have any evidence for this, or is it just your assumption, > because "why would they not be?" You mean GCC specifically or some examples of build chain attacks in general? Because in the second case there are some nice specimens out there. Cheers - t 
   
  
 

Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems]

[tomas]

On Thu, Mar 04, 2021 at 08:10:45AM -0500, Celejar wrote:
> On Thu, 4 Mar 2021 09:41:13 +
> Joe  wrote:
> 
> ...
> 
> > Undoubtedly. But there is also no doubt that gcc and every other
> > serious compiler in the West has been compromised. Why would they *not*
> > be?
> 
> Do you have any evidence for this, or is it just your assumption,
> because "why would they not be?"

You mean GCC specifically or some examples of build chain attacks
in general? Because in the second case there are some nice specimens
out there.

Cheers
 - t


signature.asc
Description: Digital signature

Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems]

[Celejar]

On Thu, 4 Mar 2021 09:41:13 +
Joe  wrote:

...

> Undoubtedly. But there is also no doubt that gcc and every other
> serious compiler in the West has been compromised. Why would they *not*
> be?

Do you have any evidence for this, or is it just your assumption,
because "why would they not be?"

> > The one aspect missing is, though, the "social" aspect: the software
> > endeavour has become so devilishly complex that the idea of One
> > Person (TM) checking everything down to some hypothetical "Trust
> > Roots" is... theoretical, to state it politely. You gotta delegate
> > some trust (well, most of it, actually).
> 
> Indeed. The new heartbeat/data return function in OpenSSL, itself the
> core of much Open Source security, was suggested by the programmer
> himself, and the resulting code was audited by *one* other person before
> approval and distribution. What could possibly go wrong?

The problem I have with your claim is that AFAIK none of the ostensible
compromises you assume exist have ever been discovered. I know there's
speculation that this was a backdoor:

https://www.debian.org/security/2008/dsa-1571
https://freedom-to-tinker.com/2013/09/20/software-transparency-debian-openssl-bug/

but that's never been established, and my understanding is that it's
considered unlikely.

I guess there's Dual_EC_DRBG, but even that, IIUC, is only speculation.

Human beings being what they are, is it really plausible that no one
involved has ever let the cat out of the bag? Are the TLAs really that
good at what they do? I mean, we have Snowden ...

Celejar

Re: PARTIAL DIAGNOSIS of Installation problems

[Richard Owlett]

On 03/03/2021 09:22 AM, Richard Owlett wrote:

I've one fine machine running i386 flavor of Debian 9.13 .
I've wish to install 64 bit flavor on a second machine.
debian-10.8.0-amd64-netinst.iso was successfully downloaded & saved.
It was copied to a USB flash drive and installation attempted.
Only did minimal install as I could not connect to internet.

To eliminate possibility that second was itself defective I attempted a 
multi-boot install to the first machine [Dell Latitude E6410].

Essentially same result :{

Connection to internet is via a T-Mobile Alcatel Linkzone Hotspot.
The WiFi connectivity programmatically disabled (i.e. it is effectively 
just a modem).

It is detected by lsusb as:
  Bus 002 Device 008: ID 1bbb:0195 T & A Mobile Phones
No non-free driver is needed as none are on the working system.

I attempted to configure the ethernet device with the numeric URL the 
working machine uses when configuring it. The installer was happy until 
it tried to connect to a chosen mirror. I tried 3 in the United States 
and 1 in Canada. None worked.


As I can boot a working Debian on that machine, all installer logs for 
the failed install are conveniently available.


Also I didn't find anything in 
https://www.debian.org/releases/stable/amd64/ telling details of how to 
set up a "ethernet" device.


What do I do now?
TIA



What I do now is make yet another attempt to convey my problem.

My universe consists of:
  1. myself.
  2. a laptop onto which I wish to install Debian using a netinst.iso .
  3. an Alcatel Linkzone sold me by T-Mobile, my ISP.
 T-Mobile erroneously ASSUMES that *all* customers will use it as a
 WiFi Hotspot to create a LAN of up to 15 devices.
 I, however, disable the WiFi as that function has *NO* value to me.
  4. Debian, absent *ANY* non-free drivers, which is slightly schizoid
 in that:
 a. it will happily connect to internet if it was installed from an
image of DVD1.
 b. its installer which assumes one has *exactly* 2 ways to connect
WiFi
"ethernet" N.B. the quotes and use of lower case
  5. the internet which has all the privacy of a party-line from over
 three score and ten in the past.

Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems]

[mick crane]

On 2021-03-04 09:41, Joe wrote:


Of course. Any externally-supplied network device is inherently
untrusted. It is unwise to give any IoT device access to your network,
it is fail-safe to assume that every such device reports back as much
as possible to some Chinese company.


Most certainly. The Wifi for the CCTV I purchased would only function 
through a far eastern server.

Why would they do that ?

mick

--
Key ID4BFEBB31

Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems]

[Joe]

On Thu, 4 Mar 2021 09:43:57 +0100
 wrote:

> On Wed, Mar 03, 2021 at 05:42:36PM -0800, David Christensen wrote:
> 
> [...]
> 
> > So, you designed, built, and programmed your "single other machine"
> > using machines that you designed, built [...]  
> 
> This is disingenuous.
> 
> The whole game is about trust. I trust gcc more than I trust MSVC.

Undoubtedly. But there is also no doubt that gcc and every other
serious compiler in the West has been compromised. Why would they *not*
be?



> The one aspect missing is, though, the "social" aspect: the software
> endeavour has become so devilishly complex that the idea of One
> Person (TM) checking everything down to some hypothetical "Trust
> Roots" is... theoretical, to state it politely. You gotta delegate
> some trust (well, most of it, actually).

Indeed. The new heartbeat/data return function in OpenSSL, itself the
core of much Open Source security, was suggested by the programmer
himself, and the resulting code was audited by *one* other person before
approval and distribution. What could possibly go wrong?

> 
> And oh, do you a favour and dare a step forward from the 1984s.
> Read David A. Wheeler's work [1] and put yourself in the 2010s :-)
> 
> Back to the topic: I do trust my ISP significantly less than I do
> OpenWRT. Therefore there is something between their provided router
> and my home network.

Of course. Any externally-supplied network device is inherently
untrusted. It is unwise to give any IoT device access to your network,
it is fail-safe to assume that every such device reports back as much
as possible to some Chinese company. But most people do unwise things
frequently, as most of us are unwise in many areas. We just happen to
know a bit about networking.

-- 
Joe

Re: PARTIAL DIAGNOSIS of Installation problems

[tomas]

On Wed, Mar 03, 2021 at 11:08:40PM -0500, Stefan Monnier wrote:
> > https://users.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf
> 
> Not sure how this is relevant.  This is like talking about the security
> of locks when the other guy is openly telling you he has a copy of
> the key.

:-)

Once I read this metaphor (I can't remember where; something tells me
that it was Bruce Schneier, but I can't find it) of securing your house
by ramming a two-by-four [1] into the earth in your front yard and
hoping the burglar hits his head against it.

Cheers

[1] https://en.wikipedia.org/wiki/File:2_By_4_Clue_Stick.jpg

 - t


signature.asc
Description: Digital signature

Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems]

[tomas]

On Wed, Mar 03, 2021 at 05:42:36PM -0800, David Christensen wrote:

[...]

> So, you designed, built, and programmed your "single other machine"
> using machines that you designed, built [...]

This is disingenuous.

The whole game is about trust. I trust gcc more than I trust MSVC.
That may be a good bet or a bad bet, as trust always is. I trust
Debian more than I trust, let's say, Salesforce.

I trust Debian: do you think I can vet the ~2070 packages that are
currently installed on my personal box?

Thompson's "on trusting trust" is just a bad joke when put in that
perspective.

I am well aware of the importance of Thompson's paper, mind you. It
was seminal in showing the importance of the build chain. NixOS and
Guix wouldn't be without that perspective. It has been demonstrated
practically a couple of times since then (MSVC, npm, etc.).

The one aspect missing is, though, the "social" aspect: the software
endeavour has become so devilishly complex that the idea of One
Person (TM) checking everything down to some hypothetical "Trust
Roots" is... theoretical, to state it politely. You gotta delegate
some trust (well, most of it, actually).

And oh, do you a favour and dare a step forward from the 1984s.
Read David A. Wheeler's work [1] and put yourself in the 2010s :-)

Back to the topic: I do trust my ISP significantly less than I do
OpenWRT. Therefore there is something between their provided router
and my home network.

Cheers

[1] https://dwheeler.com/trusting-trust/
https://arxiv.org/abs/1004.5534

 - t


signature.asc
Description: Digital signature

Re: PARTIAL DIAGNOSIS of Installation problems

[Stefan Monnier]

> https://users.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf

Not sure how this is relevant.  This is like talking about the security
of locks when the other guy is openly telling you he has a copy of
the key.


Stefan

Re: PARTIAL DIAGNOSIS of Installation problems

[David Christensen]

On 3/3/21 6:43 PM, Stefan Monnier wrote:

Or, get Internet service that includes a modem/ gateway with an Ethernet
port.  This is probably the best answer in the long run.

Unless that modem/gateway is under the control of the ISP, in which case
you're fundamentally inviting your ISP onto your local network, IOW into
your private home.
[ Tho, of course, you can probably arrange to confine that "local
network" such that it's only connected to a single other machine which
you do control and which you use as your own local router.  ]

So, you designed, built, and programmed your "single other machine" using
machines that you designed, built, and programmed; which in turn you
designed, built, and programmed using machines that you designed, built, and
programmed; etc.; all sourced from raw materials?


I didn't say "built by the ISP" but "under the control of the ISP".

IOW "who can administer".

Of course, there can also be issues of trust about the underlying
software, hardware or what not, but if the ISP has administrative
access then there's no need to dig any further.



https://users.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf


David

Re: PARTIAL DIAGNOSIS of Installation problems

[Stefan Monnier]

>>> Or, get Internet service that includes a modem/ gateway with an Ethernet
>>> port.  This is probably the best answer in the long run.
>> Unless that modem/gateway is under the control of the ISP, in which case
>> you're fundamentally inviting your ISP onto your local network, IOW into
>> your private home.
>> [ Tho, of course, you can probably arrange to confine that "local
>>network" such that it's only connected to a single other machine which
>>you do control and which you use as your own local router.  ]
> So, you designed, built, and programmed your "single other machine" using
> machines that you designed, built, and programmed; which in turn you
> designed, built, and programmed using machines that you designed, built, and
> programmed; etc.; all sourced from raw materials?

I didn't say "built by the ISP" but "under the control of the ISP".

IOW "who can administer".

Of course, there can also be issues of trust about the underlying
software, hardware or what not, but if the ISP has administrative
access then there's no need to dig any further.


Stefan

Re: PARTIAL DIAGNOSIS of Installation problems

[David Christensen]

On 3/3/21 1:53 PM, Stefan Monnier wrote:

Or, get Internet service that includes a modem/ gateway with an Ethernet
port.  This is probably the best answer in the long run.


Unless that modem/gateway is under the control of the ISP, in which case
you're fundamentally inviting your ISP onto your local network, IOW into
your private home.
[ Tho, of course, you can probably arrange to confine that "local
   network" such that it's only connected to a single other machine which
   you do control and which you use as your own local router.  ]



So, you designed, built, and programmed your "single other machine" 
using machines that you designed, built, and programmed; which in turn 
you designed, built, and programmed using machines that you designed, 
built, and programmed; etc.; all sourced from raw materials?



David

Re: PARTIAL DIAGNOSIS of Installation problems

[Stefan Monnier]

> Or, get Internet service that includes a modem/ gateway with an Ethernet
> port.  This is probably the best answer in the long run.

Unless that modem/gateway is under the control of the ISP, in which case
you're fundamentally inviting your ISP onto your local network, IOW into
your private home.
[ Tho, of course, you can probably arrange to confine that "local
  network" such that it's only connected to a single other machine which
  you do control and which you use as your own local router.  ]


Stefan

Re: PARTIAL DIAGNOSIS of Installation problems

[David Christensen]

On 3/3/21 7:22 AM, Richard Owlett wrote:

I've one fine machine running i386 flavor of Debian 9.13 .
I've wish to install 64 bit flavor on a second machine.
debian-10.8.0-amd64-netinst.iso was successfully downloaded & saved.
It was copied to a USB flash drive and installation attempted.
Only did minimal install as I could not connect to internet.

To eliminate possibility that second was itself defective I attempted a 
multi-boot install to the first machine [Dell Latitude E6410].

Essentially same result :{

Connection to internet is via a T-Mobile Alcatel Linkzone Hotspot.
The WiFi connectivity programmatically disabled (i.e. it is effectively 
just a modem).

It is detected by lsusb as:
  Bus 002 Device 008: ID 1bbb:0195 T & A Mobile Phones
No non-free driver is needed as none are on the working system.

I attempted to configure the ethernet device with the numeric URL the 
working machine uses when configuring it. The installer was happy until 
it tried to connect to a chosen mirror. I tried 3 in the United States 
and 1 in Canada. None worked.


As I can boot a working Debian on that machine, all installer logs for 
the failed install are conveniently available.


Also I didn't find anything in 
https://www.debian.org/releases/stable/amd64/ telling details of how to 
set up a "ethernet" device.


What do I do now?


If you have a Windows PC with an Ethernet port, insert the USB modem 
into the Windows PC, connect to the Internet, share the Internet 
connection to the Ethernet port, and connect the Ethernet port of the 
Windows computer to the Ethernet port of the Linux computer.



Or, use the Debian i386 machine instead of a Windows PC.


Or, get Internet service that includes a modem/ gateway with an Ethernet 
port.  This is probably the best answer in the long run.



David

PARTIAL DIAGNOSIS of Installation problems

[Richard Owlett]

I've one fine machine running i386 flavor of Debian 9.13 .
I've wish to install 64 bit flavor on a second machine.
debian-10.8.0-amd64-netinst.iso was successfully downloaded & saved.
It was copied to a USB flash drive and installation attempted.
Only did minimal install as I could not connect to internet.

To eliminate possibility that second was itself defective I attempted a 
multi-boot install to the first machine [Dell Latitude E6410].

Essentially same result :{

Connection to internet is via a T-Mobile Alcatel Linkzone Hotspot.
The WiFi connectivity programmatically disabled (i.e. it is effectively 
just a modem).

It is detected by lsusb as:
 Bus 002 Device 008: ID 1bbb:0195 T & A Mobile Phones
No non-free driver is needed as none are on the working system.

I attempted to configure the ethernet device with the numeric URL the 
working machine uses when configuring it. The installer was happy until 
it tried to connect to a chosen mirror. I tried 3 in the United States 
and 1 in Canada. None worked.


As I can boot a working Debian on that machine, all installer logs for 
the failed install are conveniently available.


Also I didn't find anything in 
https://www.debian.org/releases/stable/amd64/ telling details of how to 
set up a "ethernet" device.


What do I do now?
TIA