fix for no ssh

classic Classic list List threaded Threaded
56 messages Options
123
Reply | Threaded
Open this post in threaded view
|

fix for no ssh

Gene Heskett-4
Greetings;

Maybe I shouldn't publish this, but I found a fix for the no ssh on
reboot till you start it from it's own keyboard. It bypasses someones
paranoia.  If interested, pm me.
 
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 <http://geneslinuxbox.net:6309/gene>

Reply | Threaded
Open this post in threaded view
|

Re: fix for no ssh

Tixy-2
On Sun, 2019-07-07 at 10:29 -0400, Gene Heskett wrote:
> Greetings;
>
> Maybe I shouldn't publish this, but I found a fix for the no ssh on
> reboot till you start it from it's own keyboard. It bypasses
> someones
> paranoia.  If interested, pm me.

Why not just let us know? If it's a Debian related thing and not just
Raspian then I'm sure lots of us who have remote servers to administer
would want forewarning on how to ensure SSH comes up at boot.

I note that the release notes for Buster say it comes with AppArmour by
default, it you issue related to that?

--
Tixy

Reply | Threaded
Open this post in threaded view
|

Re: fix for no ssh

Andrei POPESCU-2
On Du, 07 iul 19, 15:45:33, Tixy wrote:

> On Sun, 2019-07-07 at 10:29 -0400, Gene Heskett wrote:
> > Greetings;
> >
> > Maybe I shouldn't publish this, but I found a fix for the no ssh on
> > reboot till you start it from it's own keyboard. It bypasses
> > someones
> > paranoia.  If interested, pm me.
>
> Why not just let us know? If it's a Debian related thing and not just
> Raspian then I'm sure lots of us who have remote servers to administer
> would want forewarning on how to ensure SSH comes up at boot.
>
> I note that the release notes for Buster say it comes with AppArmour by
> default, it you issue related to that?
It sounds a lot like this issue:
https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#entropy-starvation

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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: fix for no ssh

Nicholas Geovanis-2
Wow. Another reason to love systemd :-(
Another reason to perform fresh installs rather than upgrades whenever possible.

On Sun, Jul 7, 2019, 11:44 AM Andrei POPESCU <[hidden email]> wrote:
On Du, 07 iul 19, 15:45:33, Tixy wrote:
> On Sun, 2019-07-07 at 10:29 -0400, Gene Heskett wrote:
> > Greetings;
> >
> > Maybe I shouldn't publish this, but I found a fix for the no ssh on
> > reboot till you start it from it's own keyboard. It bypasses
> > someones
> > paranoia.  If interested, pm me.
>
> Why not just let us know? If it's a Debian related thing and not just
> Raspian then I'm sure lots of us who have remote servers to administer
> would want forewarning on how to ensure SSH comes up at boot.
>
> I note that the release notes for Buster say it comes with AppArmour by
> default, it you issue related to that?

It sounds a lot like this issue:
https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#entropy-starvation

Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
Reply | Threaded
Open this post in threaded view
|

Re: fix for no ssh

Gene Heskett-4
In reply to this post by Tixy-2
On Sunday 07 July 2019 10:45:33 Tixy wrote:

> On Sun, 2019-07-07 at 10:29 -0400, Gene Heskett wrote:
> > Greetings;
> >
> > Maybe I shouldn't publish this, but I found a fix for the no ssh on
> > reboot till you start it from it's own keyboard. It bypasses
> > someones
> > paranoia.  If interested, pm me.
>
> Why not just let us know?

Because the next update will then bring a fix for my fix.  Smarter mice
theory at work.

> If it's a Debian related thing and not just
> Raspian then I'm sure lots of us who have remote servers to administer
> would want forewarning on how to ensure SSH comes up at boot.

At this point I don't know if its debian only.

> I note that the release notes for Buster say it comes with AppArmour
> by default, it you issue related to that?

Nope. And I see no indicators that apparmour is running, and have done
nothing to stop it on the pi I'm trying to use. I would, if it gives me
any hassle, purge it. It, nor selinux, is worth their storage space on
the media. I might change my mind if this local network was multi-user,
but I'm the only one putting finger prints on the keys here, until I
miss roll call the last time

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 <http://geneslinuxbox.net:6309/gene>

Reply | Threaded
Open this post in threaded view
|

Re: fix for no ssh

Andrei POPESCU-2
In reply to this post by Nicholas Geovanis-2
On Du, 07 iul 19, 12:44:30, Nicholas Geovanis wrote:
> Wow. Another reason to love systemd :-(

Not clear to me why you are blaming systemd here.

In my understanding what sysv-init does (crediting entropy over reboots)
is not secure for various reasons.

> Another reason to perform fresh installs rather than upgrades whenever
> possible.

How is that supposed to help?

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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: fix for no ssh

Curt
In reply to this post by Andrei POPESCU-2
On 2019-07-07, Andrei POPESCU <[hidden email]> wrote:

>
> It sounds a lot like this issue:
> https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#entropy-starvation

 Due to systemd needing entropy during boot and the kernel treating such calls
 as blocking when available entropy is low, the system may hang for minutes to
 hours until the randomness subsystem is sufficiently initialized (random: crng
 init done). For amd64 systems supporting the RDRAND instruction this issue is
 avoided by the Debian kernel using this instruction by default
(CONFIG_RANDOM_TRUST_CPU).

For amd64 systems with the RDRAND instruction, the euphemistically termed
"issue" (hanging for minutes or hours!) is "avoided."

That avoidance is wonderful news for me, as I happen to have an amd64 system
myself. But does it support the RDRAND instruction? How do I find out? What do
I do if it doesn't? Here the notes suffer from a maddening silence.

At any rate, I case-insensitively grepped for the RDRAND flag in /proc/cpuinfo
and came up with nada (this is a pretty old machine), if that is indeed how you
discover whether you have the instruction or not.

But now I'm uncertain whether this bug will affect me or not.

https://daniel-lange.com/archives/152-Openssh-taking-minutes-to-become-available,-booting-takes-half-an-hour-...-because-your-server-waits-for-a-few-bytes-of-randomness.html

https://lists.debian.org/debian-devel/2018/12/msg00184.html

I guess I would not be affected because I'm not running an entropy-hungry
service (or any services at all), but what a PITA to have gone on this wild
goose chase to finally find that out (if true). These release-notes for Buster,
as they stand, are apparently both wrong (migration of interface names) and
misleading (if the entropy-starvation stanza had begun, "For those running
services using the  getrandom() system call..." or something, I probably
wouldn't be here cluttering the forum with my bullshit).

> Kind regards, Andrei


Reply | Threaded
Open this post in threaded view
|

Re: fix for no ssh

Andrei POPESCU-2
On Lu, 08 iul 19, 08:40:06, Curt wrote:
>
> I guess I would not be affected because I'm not running an entropy-hungry
> service (or any services at all), but what a PITA to have gone on this wild
> goose chase to finally find that out (if true). These release-notes for Buster,
> as they stand, are apparently both wrong (migration of interface names) and

This was fixed before the release.

You are aware that the Release Notes are work in progress as long as the
corresponding Debian release is still in testing, right?

> misleading (if the entropy-starvation stanza had begun, "For those running
> services using the  getrandom() system call..." or something, I probably
> wouldn't be here cluttering the forum with my bullshit).

Patches welcome.

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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: fix for no ssh

Curt
In reply to this post by Andrei POPESCU-2
On 2019-07-08, Andrei POPESCU <[hidden email]> wrote:
>
>> Wow. Another reason to love systemd :-(
>
> Not clear to me why you are blaming systemd here.
>

Because systemd is to blame (at least in the opinion of some people in the
know, like Stefan Frisch, for instance):

https://qa.debian.org/developer.php?login=sf@...

https://lists.debian.org/debian-devel/2018/12/msg00184.html

...
 
 The systemd maintainers argue that individual services should handle this
 problem [1,2]. But this does not scale and the whole point of the getrandom()
 syscall is that it cannot fail and that its users do not need fallback code
 that is not well-tested and probably buggy. [5]

> In my understanding what sysv-init does (crediting entropy over reboots)
> is not secure for various reasons.

...

 The problem is that systemd (and probably /etc/init.d/urandom, too) does not set
 the flag that allows the kernel to credit the randomness and so the kernel does
 not know about the entropy contained in that file. Systemd upstream argues that
 this is supposed to protect against the same OS image being used many times
 [3]. (More links to more discussion can be found at [4]).

 But an identical OS image needs to be modified anyway in order to be secure
 (re-create ssh host keys, change root password, re-create ssl-cert's private
 keys, etc.). Injecting some entropy in some way is just another task that
 needs to be done for that use case.  So basically the current implementation
 of systemd-random-seed.service breaks stuff for everyone while not fixing the
 thing they are claiming to fix.

>> Another reason to perform fresh installs rather than upgrades whenever
>> possible.
>
> How is that supposed to help?
>
> Kind regards,
> Andrei


--
"These findings demonstrate that under appropriate conditions the isolated,
intact large mammalian brain possesses an underappreciated capacity for
restoration of microcirculation and molecular and cellular activity after a
prolonged post-mortem interval." From a recent article in *Nature*. Holy shit.

Reply | Threaded
Open this post in threaded view
|

Re: fix for no ssh

Curt
In reply to this post by Andrei POPESCU-2
On 2019-07-08, Andrei POPESCU <[hidden email]> wrote:
>
> This was fixed before the release.

What?

> You are aware that the Release Notes are work in progress as long as the
> corresponding Debian release is still in testing, right?
>

How will the mistakes be fixed if no one points them out?

>> misleading (if the entropy-starvation stanza had begun, "For those running
>> services using the  getrandom() system call..." or something, I probably
>> wouldn't be here cluttering the forum with my bullshit).

> Patches welcome.
>

I've given them. Delete the erroneous stanza concerning the migration of
inteface names, and begin the stanza concerning the critcial systemd bug
as above (rephrases welcome).


--
"These findings demonstrate that under appropriate conditions the isolated,
intact large mammalian brain possesses an underappreciated capacity for
restoration of microcirculation and molecular and cellular activity after a
prolonged post-mortem interval." From a recent article in *Nature*. Holy shit.

Reply | Threaded
Open this post in threaded view
|

Re: fix for no ssh

Andrei POPESCU-2
On Lu, 08 iul 19, 09:06:33, Curt wrote:
> On 2019-07-08, Andrei POPESCU <[hidden email]> wrote:
> >
> > This was fixed before the release.
>
> What?

Is there something wrong with the current wording?
 
> > You are aware that the Release Notes are work in progress as long as the
> > corresponding Debian release is still in testing, right?
>
> How will the mistakes be fixed if no one points them out?

Yes, please! I'm sure you know how to use reportbug ;)
 

> >> misleading (if the entropy-starvation stanza had begun, "For those running
> >> services using the  getrandom() system call..." or something, I probably
> >> wouldn't be here cluttering the forum with my bullshit).
>
> > Patches welcome.
> >
>
> I've given them. Delete the erroneous stanza concerning the migration of
> inteface names, and begin the stanza concerning the critcial systemd bug
> as above (rephrases welcome).
I have no idea which daemons on my system are using getramdom().

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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: fix for no ssh

Curt
On 2019-07-08, Andrei POPESCU <[hidden email]> wrote:
>
> On Lu, 08 iul 19, 09:06:33, Curt wrote:
>> On 2019-07-08, Andrei POPESCU <[hidden email]> wrote:
>> >
>> > This was fixed before the release.

>> What?
>
> Is there something wrong with the current wording?

I guess, as I thought I was referring to the release-notes, which
haven't been.

>> > You are aware that the Release Notes are work in progress as long
>> > as the
>> > corresponding Debian release is still in testing, right?

>> How will the mistakes be fixed if no one points them out?

> Yes, please! I'm sure you know how to use reportbug ;)

Actually, I don't, but I could give it a try. There was some uncertainty
in a recent thread about whether "it" had been fixed or not.

>> >> misleading (if the entropy-starvation stanza had begun, "For those running
>> >> services using the  getrandom() system call..." or something, I
>> >> probably wouldn't be here cluttering the forum with my bullshit).

>> > Patches welcome.

>> I've given them. Delete the erroneous stanza concerning the migration of
>> inteface names, and begin the stanza concerning the critcial systemd bug
>> as above (rephrases welcome).
>
> I have no idea which daemons on my system are using getramdom().

You got me there. AFAIK, openssh and openssl.

> Kind regards,
> Andrei


--
"These findings demonstrate that under appropriate conditions the isolated,
intact large mammalian brain possesses an underappreciated capacity for
restoration of microcirculation and molecular and cellular activity after a
prolonged post-mortem interval." From a recent article in *Nature*. Holy shit.

Reply | Threaded
Open this post in threaded view
|

Re: fix for no ssh

Andrei POPESCU-2
On Lu, 08 iul 19, 09:44:51, Curt wrote:

> On 2019-07-08, Andrei POPESCU <[hidden email]> wrote:
> >
> > On Lu, 08 iul 19, 09:06:33, Curt wrote:
> >> On 2019-07-08, Andrei POPESCU <[hidden email]> wrote:
> >> >
> >> > This was fixed before the release.
>
> >> What?
> >
> > Is there something wrong with the current wording?
>
> I guess, as I thought I was referring to the release-notes, which
> haven't been.
English is not my first language so I'm not sure what you mean here.
Please kindly rephrase.

If there is still some inaccuracy please do provide more details
(preferably with references) otherwise it's impossible to fix.
 
> > Yes, please! I'm sure you know how to use reportbug ;)
>
> Actually, I don't, but I could give it a try.

You've been using Debian long enough, I'm sure you'll work it out ;)

> There was some uncertainty in a recent thread about whether "it" had
> been fixed or not.

With "it" being...

> > I have no idea which daemons on my system are using getramdom().
>
> You got me there. AFAIK, openssh and openssl.

Apparently nowadays many daemons need it, and not only for encryption
(e.g. to generate UUIDs).

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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: fix for no ssh

Andrei POPESCU-2
In reply to this post by Curt
On Lu, 08 iul 19, 09:01:36, Curt wrote:

> On 2019-07-08, Andrei POPESCU <[hidden email]> wrote:
> >
> >> Wow. Another reason to love systemd :-(
> >
> > Not clear to me why you are blaming systemd here.
>
> Because systemd is to blame (at least in the opinion of some people in the
> know, like Stefan Frisch, for instance):
>
> https://qa.debian.org/developer.php?login=sf@...
>
> https://lists.debian.org/debian-devel/2018/12/msg00184.html
>
> ...
>
>  The problem is that systemd (and probably /etc/init.d/urandom, too) does not set
>  the flag that allows the kernel to credit the randomness and so the kernel does
>  not know about the entropy contained in that file. Systemd upstream argues that
>  this is supposed to protect against the same OS image being used many times
>  [3]. (More links to more discussion can be found at [4]).
>
>  But an identical OS image needs to be modified anyway in order to be secure
>  (re-create ssh host keys, change root password, re-create ssl-cert's private
>  keys, etc.). Injecting some entropy in some way is just another task that
>  needs to be done for that use case.  So basically the current implementation
>  of systemd-random-seed.service breaks stuff for everyone while not fixing the
>  thing they are claiming to fix.
Oh, right. Read this before, but forgot about it.

Even if the upstream systemd developers are right (and I don't have
anywhere near the expertise to judge on that), they could have handled
it better.

The timing was also not very good for the buster release cycle.
Hopefully this will be sorted out properly in time for bullseye.

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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: fix for no ssh

Curt
In reply to this post by Andrei POPESCU-2
On 2019-07-08, Andrei POPESCU <[hidden email]> wrote:
>
>
> On Lu, 08 iul 19, 09:44:51, Curt wrote:
>> On 2019-07-08, Andrei POPESCU <[hidden email]> wrote:
>> >
>> > On Lu, 08 iul 19, 09:06:33, Curt wrote:
>> >> On 2019-07-08, Andrei POPESCU <[hidden email]> wrote:
>> >> >
>> >> > This was fixed before the release.

>> >> What?
>> >
>> > Is there something wrong with the current wording?

>> I guess, as I thought I was referring to the release-notes, which
>> haven't been.

> English is not my first language so I'm not sure what you mean here.
> Please kindly rephrase.

I thought you were saying that
'/etc/udev/rules.d/70-persistent-net.rules' remains a valid mechanism
for defining interface names in Buster (fixed). But the release-notes
(hmm, I think they've been modified since I last looked and now state
that that file is no longer "officially" supported by udev---but may
work in some cases). So I wouldn't be filing a bug report against that
stanza any longer, as current situation seems unverifiable.

Sorry if I'm unclear.

> If there is still some inaccuracy please do provide more details
> (preferably with references) otherwise it's impossible to fix.

>> > Yes, please! I'm sure you know how to use reportbug ;)

>> Actually, I don't, but I could give it a try.
>
> You've been using Debian long enough, I'm sure you'll work it out ;)
>
>> There was some uncertainty in a recent thread about whether "it" had
>> been fixed or not.
>
> With "it" being...

Whether '/etc/udev/rules.d/70-persistent-net.rules' was respected or not
as means of defining interface names.

>> > I have no idea which daemons on my system are using getramdom().
>
>> You got me there. AFAIK, openssh and openssl.
>
> Apparently nowadays many daemons need it, and not only for encryption
> (e.g. to generate UUIDs).

Well, at the very least people should be informed who is likely to be
affected by the bug, and for those using amd64 how to check for the RDRAND
instruction, as well as what to do about it if they don't have it
(that's what I'd like to know, at any rate).

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

--
"These findings demonstrate that under appropriate conditions the isolated,
intact large mammalian brain possesses an underappreciated capacity for
restoration of microcirculation and molecular and cellular activity after a
prolonged post-mortem interval." From a recent article in *Nature*. Holy shit.

Reply | Threaded
Open this post in threaded view
|

Re: fix for no ssh

Curt
In reply to this post by Andrei POPESCU-2
On 2019-07-08, Andrei POPESCU <[hidden email]> wrote:
>
> The timing was also not very good for the buster release cycle.
> Hopefully this will be sorted out properly in time for bullseye.

That would be great. Then if they could resuscitate ecryptfs-utils
I would be a happy camper.

;-)

> Kind regards,
> Andrei
>


--
"These findings demonstrate that under appropriate conditions the isolated,
intact large mammalian brain possesses an underappreciated capacity for
restoration of microcirculation and molecular and cellular activity after a
prolonged post-mortem interval." From a recent article in *Nature*. Holy shit.

Reply | Threaded
Open this post in threaded view
|

Re: fix for no ssh

Curt
In reply to this post by Andrei POPESCU-2
On 2019-07-08, Andrei POPESCU <[hidden email]> wrote:
>
> The timing was also not very good for the buster release cycle.
> Hopefully this will be sorted out properly in time for bullseye.

Earlier I thought bullseye was some sort of idiom for Buster going live.
Color me ignorant.

But concerning the currently proposed workaround for x86 CPU's (from
which I cannot "benefit," apparently), it's edifying to note what Ted
himself said about his own patch:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=39a8883a2b989d1d21bd8dd99f5557f0c5e89694

 random: add a config option to trust the CPU's hwrng

 This gives the user building their own kernel (or a Linux distribution)
 the option of deciding whether or not to trust the CPU's hardware
 random number generator (e.g., RDRAND for x86 CPU's) as being correctly
 implemented and not having a back door introduced (perhaps courtesy of
 a Nation State's law enforcement or intelligence agencies).

 This will prevent getrandom(2) from blocking, if there is a
 willingness to trust the CPU manufacturer.

 Signed-off-by: Theodore Ts'o <[hidden email]>

So Debian Buster, as it now stands and I understand it, trusts in the
correctness of the hardware random number generator, as well as in the
absence of any back door that might compromise it, universally and
without qualification, of every Debian Buster user's x86 cpu (default
kernel command line CONFIG_RANDOM_TRUST_CPU), in the name of security.

That's a safer solution than installing haveged?

I know, I know, I can use any kernel command line I want. I could switch
to another distribution without these problems. I could go fuck myself.
But as an innate altruist (just kidding), I'm wondering whether the
regular user is aware of the implications of all this. What about people
in Nation States ...  Well, you get the idea.

> Kind regards,
> Andrei


--
"These findings demonstrate that under appropriate conditions the isolated,
intact large mammalian brain possesses an underappreciated capacity for
restoration of microcirculation and molecular and cellular activity after a
prolonged post-mortem interval." From a recent article in *Nature*. Holy shit.

Reply | Threaded
Open this post in threaded view
|

Re: fix for no ssh

Greg Wooledge
On Mon, Jul 08, 2019 at 02:40:16PM -0000, Curt wrote:
> Earlier I thought bullseye was some sort of idiom for Buster going live.
> Color me ignorant.

Bullseye will be the next version of Debian after buster, probably in
2-3 years.  Cue the confusion about two similar-looking release names
back to back.

> So Debian Buster, as it now stands and I understand it, trusts in the
> correctness of the hardware random number generator, as well as in the
> absence of any back door that might compromise it, universally and
> without qualification, of every Debian Buster user's x86 cpu (default
> kernel command line CONFIG_RANDOM_TRUST_CPU), in the name of security.
>
> That's a safer solution than installing haveged?

I don't have any opinions at this time about the trustworthiness of
various x86 CPU RDRAND instructions, but...

What on earth happened to simply saving entropy on disk across reboots?
Why isn't there an option simply to do that?  I get that it may be an
issue for certain kinds of virtual machines, but I give less than one
crap about virtual machines.  Can I get the previous sensible behavior
as an option for my physical machines?

Reply | Threaded
Open this post in threaded view
|

[OT] Trustfulness. Was: Re: fix for no ssh

Thomas Schmitt
In reply to this post by Curt
Hi,

Curt quoted:
>  This will prevent getrandom(2) from blocking, if there is a
>  willingness to trust the CPU manufacturer.
>  Signed-off-by: Theodore Ts'o <[hidden email]>

Apropos trusting strange allies:

  # mount debian-10.0.0-amd64-netinst.iso /mnt/iso
  mount: /dev/loop0 is write-protected, mounting read-only
  # mount /mnt/iso/boot/grub/efi.img /mnt/fat
  # strings /mnt/fat/efi/boot/bootx64.efi | fgrep Microsoft | wc -l
  43

It is futile to change the table cloth before the pig is out of the soup
  http://iartprints.com/uploadpic/michael_sowa/big/pig_in_soup.jpg


Have a nice day :)

Thomas

Reply | Threaded
Open this post in threaded view
|

Re: [OT] Trustfulness. Was: Re: fix for no ssh

Reco
        Hi.

On Mon, Jul 08, 2019 at 05:57:49PM +0200, Thomas Schmitt wrote:

> Hi,
>
> Curt quoted:
> >  This will prevent getrandom(2) from blocking, if there is a
> >  willingness to trust the CPU manufacturer.
> >  Signed-off-by: Theodore Ts'o <[hidden email]>
>
> Apropos trusting strange allies:
>
>   # mount debian-10.0.0-amd64-netinst.iso /mnt/iso
>   mount: /dev/loop0 is write-protected, mounting read-only
>   # mount /mnt/iso/boot/grub/efi.img /mnt/fat
>   # strings /mnt/fat/efi/boot/bootx64.efi | fgrep Microsoft | wc -l
>   43
>
> It is futile to change the table cloth before the pig is out of the soup
>   http://iartprints.com/uploadpic/michael_sowa/big/pig_in_soup.jpg

rgrep Microsoft /lib/modules

Even if you're not using UEFI, they are still there :)

Reco

123