Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #232278 > unrolled thread
| Started by | Richard Owlett <rowlett@cloud85.net> |
|---|---|
| First post | 2021-03-02 21:10 +0100 |
| Last post | 2021-03-11 00:20 +0100 |
| Articles | 20 on this page of 84 — 20 participants |
Back to article view | Back to linux.debian.user
Installation problems Richard Owlett <rowlett@cloud85.net> - 2021-03-02 21:10 +0100
Re: Installation problems Brian <ad44@cityscape.co.uk> - 2021-03-02 21:40 +0100
Re: Installation problems Weaver <weaver@riseup.net> - 2021-03-02 22:20 +0100
Re: Installation problems <tomas@tuxteam.de> - 2021-03-02 22:30 +0100
Re: Installation problems Brian <ad44@cityscape.co.uk> - 2021-03-03 00:10 +0100
Re: Installation problems Richard Owlett <rowlett@cloud85.net> - 2021-03-02 22:50 +0100
Re: Installation problems "Andrew M.A. Cater" <amacater@einval.com> - 2021-03-02 23:20 +0100
Re: Installation problems Richard Owlett <rowlett@cloud85.net> - 2021-03-03 02:40 +0100
Re: Installation problems Richard Owlett <rowlett@cloud85.net> - 2021-03-03 02:50 +0100
Re: Installation problems Keith Bainbridge <ke1thozgroups@gmx.com> - 2021-03-03 00:00 +0100
Re: Installation problems Richard Owlett <rowlett@cloud85.net> - 2021-03-03 10:30 +0100
Re: Installation problems David Christensen <dpchrist@holgerdanske.com> - 2021-03-03 15:40 +0100
Re: Installation problems Celejar <celejar@gmail.com> - 2021-03-03 16:40 +0100
Re: Installation problems Richard Owlett <rowlett@cloud85.net> - 2021-03-03 16:40 +0100
Re: Installation problems David Christensen <dpchrist@holgerdanske.com> - 2021-03-03 22:40 +0100
Re: Installation problems Joe <joe@jretrading.com> - 2021-03-03 23:00 +0100
Re: Installation problems Richard Owlett <rowlett@cloud85.net> - 2021-03-04 13:00 +0100
Re: Installation problems Tixy <tixy@yxit.co.uk> - 2021-03-04 13:30 +0100
Re: Installation problems Richard Owlett <rowlett@cloud85.net> - 2021-03-04 14:00 +0100
Re: Installation problems Felix Miata <mrmazda@earthlink.net> - 2021-03-04 17:30 +0100
Re: Installation problems Keith Bainbridge <ke1thozgroups@gmx.com> - 2021-03-02 23:50 +0100
Re: Installation problems David Wright <deblis@lionunicorn.co.uk> - 2021-03-03 03:50 +0100
Re: Installation problems Richard Owlett <rowlett@cloud85.net> - 2021-03-03 10:50 +0100
Re: Installation problems Richard Owlett <rowlett@cloud85.net> - 2021-03-03 11:20 +0100
Re: Installation problems Keith Bainbridge <ke1thozgroups@gmx.com> - 2021-03-03 00:00 +0100
PARTIAL DIAGNOSIS of Installation problems Richard Owlett <rowlett@cloud85.net> - 2021-03-03 16:30 +0100
Re: PARTIAL DIAGNOSIS of Installation problems David Christensen <dpchrist@holgerdanske.com> - 2021-03-03 22:30 +0100
Re: PARTIAL DIAGNOSIS of Installation problems Stefan Monnier <monnier@iro.umontreal.ca> - 2021-03-03 23:00 +0100
Re: PARTIAL DIAGNOSIS of Installation problems David Christensen <dpchrist@holgerdanske.com> - 2021-03-04 02:50 +0100
Re: PARTIAL DIAGNOSIS of Installation problems Stefan Monnier <monnier@iro.umontreal.ca> - 2021-03-04 03:50 +0100
Re: PARTIAL DIAGNOSIS of Installation problems David Christensen <dpchrist@holgerdanske.com> - 2021-03-04 04:20 +0100
Re: PARTIAL DIAGNOSIS of Installation problems Stefan Monnier <monnier@iro.umontreal.ca> - 2021-03-04 05:10 +0100
Re: PARTIAL DIAGNOSIS of Installation problems <tomas@tuxteam.de> - 2021-03-04 10:00 +0100
Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems] <tomas@tuxteam.de> - 2021-03-04 09:50 +0100
Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems] Joe <joe@jretrading.com> - 2021-03-04 10:50 +0100
Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems] <tomas@tuxteam.de> - 2021-03-04 14:20 +0100
Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems] Celejar <celejar@gmail.com> - 2021-03-04 15:30 +0100
Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems] tomas@tuxteam.de - 2021-03-04 16:20 +0100
Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems] Celejar <celejar@gmail.com> - 2021-03-04 17:20 +0100
Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems] tomas@tuxteam.de - 2021-03-04 19:10 +0100
Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems] Celejar <celejar@gmail.com> - 2021-03-04 19:30 +0100
Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems] Stefan Monnier <monnier@iro.umontreal.ca> - 2021-03-04 23:20 +0100
Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems] <tomas@tuxteam.de> - 2021-03-04 23:40 +0100
Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems] Joe <joe@jretrading.com> - 2021-03-04 23:50 +0100
Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems] Celejar <celejar@gmail.com> - 2021-03-04 15:30 +0100
Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems] Celejar <celejar@gmail.com> - 2021-03-04 14:20 +0100
Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems] Joe <joe@jretrading.com> - 2021-03-04 16:10 +0100
Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems] Celejar <celejar@gmail.com> - 2021-03-04 17:20 +0100
OT: Bathroom scales (was: Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems]) rhkramer@gmail.com - 2021-03-04 17:40 +0100
Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems] David Christensen <dpchrist@holgerdanske.com> - 2021-03-04 23:30 +0100
[OFFTOPIC] Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems] Stefan Monnier <monnier@iro.umontreal.ca> - 2021-03-05 04:00 +0100
Re: [OFFTOPIC] Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems] David Christensen <dpchrist@holgerdanske.com> - 2021-03-05 06:30 +0100
Re: [OFFTOPIC] Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems] David Christensen <dpchrist@holgerdanske.com> - 2021-03-05 06:40 +0100
Re: [OFFTOPIC] Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems] Stefan Monnier <monnier@iro.umontreal.ca> - 2021-03-05 07:40 +0100
Re: [OFFTOPIC] Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems] <tomas@tuxteam.de> - 2021-03-05 09:20 +0100
Re: [OFFTOPIC] Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems] Gene Heskett <gheskett@shentel.net> - 2021-03-05 15:10 +0100
Re: PARTIAL DIAGNOSIS of Installation problems Richard Owlett <rowlett@cloud85.net> - 2021-03-04 13:30 +0100
Re: PARTIAL DIAGNOSIS of Installation problems David Wright <deblis@lionunicorn.co.uk> - 2021-03-04 18:50 +0100
Re: PARTIAL DIAGNOSIS of Installation problems David Christensen <dpchrist@holgerdanske.com> - 2021-03-04 23:50 +0100
Re: PARTIAL DIAGNOSIS of Installation problems Richard Owlett <rowlett@cloud85.net> - 2021-03-05 13:20 +0100
Re: PARTIAL DIAGNOSIS of Installation problems David Christensen <dpchrist@holgerdanske.com> - 2021-03-05 21:30 +0100
Re: PARTIAL DIAGNOSIS of Installation problems Richard Owlett <rowlett@cloud85.net> - 2021-03-05 22:20 +0100
Re: PARTIAL DIAGNOSIS of Installation problems Joe <joe@jretrading.com> - 2021-03-05 22:50 +0100
Re: PARTIAL DIAGNOSIS of Installation problems Richard Owlett <rowlett@cloud85.net> - 2021-03-05 23:30 +0100
Re: PARTIAL DIAGNOSIS of Installation problems Charles Curley <charlescurley@charlescurley.com> - 2021-03-06 00:40 +0100
Re: PARTIAL DIAGNOSIS of Installation problems Celejar <celejar@gmail.com> - 2021-03-07 01:40 +0100
Re: PARTIAL DIAGNOSIS of Installation problems David Wright <deblis@lionunicorn.co.uk> - 2021-03-06 02:50 +0100
Status update {Re: PARTIAL DIAGNOSIS of Installation problems} Richard Owlett <rowlett@cloud85.net> - 2021-03-08 13:10 +0100
Re: Status update {Re: PARTIAL DIAGNOSIS of Installation problems} "Andrew M.A. Cater" <amacater@einval.com> - 2021-03-08 13:30 +0100
Re: Status update {Re: PARTIAL DIAGNOSIS of Installation problems} songbird <songbird@anthive.com> - 2021-03-08 17:30 +0100
Re: Status update {Re: PARTIAL DIAGNOSIS of Installation problems} Richard Owlett <rowlett@cloud85.net> - 2021-03-08 20:20 +0100
Re: Status update {Re: PARTIAL DIAGNOSIS of Installation problems} songbird <songbird@anthive.com> - 2021-03-09 02:10 +0100
Re: Status update {Re: PARTIAL DIAGNOSIS of Installation problems} Richard Owlett <rowlett@cloud85.net> - 2021-03-09 13:40 +0100
Re: Status update {Re: PARTIAL DIAGNOSIS of Installation problems} Anssi Saari <as@sci.fi> - 2021-03-09 14:00 +0100
Re: Status update {Re: PARTIAL DIAGNOSIS of Installation problems} Joe <joe@jretrading.com> - 2021-03-09 14:20 +0100
Re: Status update {Re: PARTIAL DIAGNOSIS of Installation problems} Andrei POPESCU <andreimpopescu@gmail.com> - 2021-03-09 14:10 +0100
Re: Status update {Re: PARTIAL DIAGNOSIS of Installation problems} Joe <joe@jretrading.com> - 2021-03-09 14:20 +0100
Re: Status update {Re: PARTIAL DIAGNOSIS of Installation problems} Richard Owlett <rowlett@cloud85.net> - 2021-03-09 21:40 +0100
Re: Status update {Re: PARTIAL DIAGNOSIS of Installation problems} Andrei POPESCU <andreimpopescu@gmail.com> - 2021-03-10 10:50 +0100
Re: Status update {Re: PARTIAL DIAGNOSIS of Installation problems} Richard Owlett <rowlett@cloud85.net> - 2021-03-10 11:30 +0100
Re: Status update {Re: PARTIAL DIAGNOSIS of Installation problems} Andrei POPESCU <andreimpopescu@gmail.com> - 2021-03-10 14:40 +0100
Re: Status update {Re: PARTIAL DIAGNOSIS of Installation problems} Richard Owlett <rowlett@cloud85.net> - 2021-03-10 15:50 +0100
Re: Status update {Re: PARTIAL DIAGNOSIS of Installation problems} Andrei POPESCU <andreimpopescu@gmail.com> - 2021-03-10 21:50 +0100
Re: Status update {Re: PARTIAL DIAGNOSIS of Installation problems} "Andrew M.A. Cater" <amacater@einval.com> - 2021-03-11 00:20 +0100
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | Celejar <celejar@gmail.com> |
|---|---|
| Date | 2021-03-04 19:30 +0100 |
| Subject | Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems] |
| Message-ID | <BP0Tw-1tY-1@gated-at.bofh.it> |
| In reply to | #232366 |
On Thu, 4 Mar 2021 19:05:38 +0100 tomas@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
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2021-03-04 23:20 +0100 |
| Subject | Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems] |
| Message-ID | <BP4u5-3IU-1@gated-at.bofh.it> |
| In reply to | #232366 |
> 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
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2021-03-04 23:40 +0100 |
| Subject | Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems] |
| Message-ID | <BP4Ns-3OT-3@gated-at.bofh.it> |
| In reply to | #232370 |
[Multipart message — attachments visible in raw view] — view raw
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
[toc] | [prev] | [next] | [standalone]
| From | Joe <joe@jretrading.com> |
|---|---|
| Date | 2021-03-04 23:50 +0100 |
| Subject | Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems] |
| Message-ID | <BP4X7-3Sm-1@gated-at.bofh.it> |
| In reply to | #232373 |
On Thu, 4 Mar 2021 23:34:25 +0100 <tomas@tuxteam.de> 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
[toc] | [prev] | [next] | [standalone]
| From | Celejar <celejar@gmail.com> |
|---|---|
| Date | 2021-03-04 15:30 +0100 |
| Subject | Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems] |
| Message-ID | <BOX9f-7nW-7@gated-at.bofh.it> |
| In reply to | #232351 |
[Please don't top post.] On Thu, 04 Mar 2021 13:39:56 +0000 Leandro neto <lemeln84@uol.com.br> 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: tomas@tuxteam.de > Enviado em: 4 de março de 2021 10:18 > Para: celejar@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 +0000 > 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
[toc] | [prev] | [next] | [standalone]
| From | Celejar <celejar@gmail.com> |
|---|---|
| Date | 2021-03-04 14:20 +0100 |
| Subject | Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems] |
| Message-ID | <BOW3v-6Mm-3@gated-at.bofh.it> |
| In reply to | #232345 |
On Thu, 4 Mar 2021 09:41:13 +0000 Joe <joe@jretrading.com> 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
[toc] | [prev] | [next] | [standalone]
| From | Joe <joe@jretrading.com> |
|---|---|
| Date | 2021-03-04 16:10 +0100 |
| Subject | Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems] |
| Message-ID | <BOXLY-7Qh-5@gated-at.bofh.it> |
| In reply to | #232353 |
On Thu, 4 Mar 2021 08:10:45 -0500 Celejar <celejar@gmail.com> wrote: > On Thu, 4 Mar 2021 09:41:13 +0000 > Joe <joe@jretrading.com> 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
[toc] | [prev] | [next] | [standalone]
| From | Celejar <celejar@gmail.com> |
|---|---|
| Date | 2021-03-04 17:20 +0100 |
| Subject | Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems] |
| Message-ID | <BOYRI-cF-5@gated-at.bofh.it> |
| In reply to | #232357 |
On Thu, 4 Mar 2021 15:05:29 +0000 Joe <joe@jretrading.com> wrote: > On Thu, 4 Mar 2021 08:10:45 -0500 > Celejar <celejar@gmail.com> wrote: > > > On Thu, 4 Mar 2021 09:41:13 +0000 > > Joe <joe@jretrading.com> 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
[toc] | [prev] | [next] | [standalone]
| From | rhkramer@gmail.com |
|---|---|
| Date | 2021-03-04 17:40 +0100 |
| Subject | OT: Bathroom scales (was: Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems]) |
| Message-ID | <BOZb3-j9-3@gated-at.bofh.it> |
| In reply to | #232357 |
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 <not that anyone needs my agreement> ;-)
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2021-03-04 23:30 +0100 |
| Subject | Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems] |
| Message-ID | <BP4DL-3LZ-1@gated-at.bofh.it> |
| In reply to | #232340 |
On 3/4/21 12:43 AM, tomas@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
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2021-03-05 04:00 +0100 |
| Subject | [OFFTOPIC] Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems] |
| Message-ID | <BP8R3-6jY-1@gated-at.bofh.it> |
| In reply to | #232371 |
> 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
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2021-03-05 06:30 +0100 |
| Subject | Re: [OFFTOPIC] Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems] |
| Message-ID | <BPbce-7Xi-3@gated-at.bofh.it> |
| In reply to | #232378 |
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
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2021-03-05 06:40 +0100 |
| Subject | Re: [OFFTOPIC] Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems] |
| Message-ID | <BPblT-80x-1@gated-at.bofh.it> |
| In reply to | #232379 |
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
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2021-03-05 07:40 +0100 |
| Subject | Re: [OFFTOPIC] Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems] |
| Message-ID | <BPchY-ak-5@gated-at.bofh.it> |
| In reply to | #232379 |
> 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
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2021-03-05 09:20 +0100 |
| Subject | Re: [OFFTOPIC] Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems] |
| Message-ID | <BPdQJ-1aB-11@gated-at.bofh.it> |
| In reply to | #232381 |
[Multipart message — attachments visible in raw view] — view raw
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
[toc] | [prev] | [next] | [standalone]
| From | Gene Heskett <gheskett@shentel.net> |
|---|---|
| Date | 2021-03-05 15:10 +0100 |
| Subject | Re: [OFFTOPIC] Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems] |
| Message-ID | <BPjjs-4ID-3@gated-at.bofh.it> |
| In reply to | #232385 |
On Friday 05 March 2021 03:14:51 tomas@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 <http://geneslinuxbox.net:6309/gene>
[toc] | [prev] | [next] | [standalone]
| From | Richard Owlett <rowlett@cloud85.net> |
|---|---|
| Date | 2021-03-04 13:30 +0100 |
| Subject | Re: PARTIAL DIAGNOSIS of Installation problems |
| Message-ID | <BOVh7-6fA-7@gated-at.bofh.it> |
| In reply to | #232311 |
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.
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2021-03-04 18:50 +0100 |
| Subject | Re: PARTIAL DIAGNOSIS of Installation problems |
| Message-ID | <BP0gO-Wa-11@gated-at.bofh.it> |
| In reply to | #232349 |
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.
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2021-03-04 23:50 +0100 |
| Subject | Re: PARTIAL DIAGNOSIS of Installation problems |
| Message-ID | <BP4X8-3Sm-3@gated-at.bofh.it> |
| In reply to | #232349 |
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
[toc] | [prev] | [next] | [standalone]
| From | Richard Owlett <rowlett@cloud85.net> |
|---|---|
| Date | 2021-03-05 13:20 +0100 |
| Subject | Re: PARTIAL DIAGNOSIS of Installation problems |
| Message-ID | <BPhB0-3uc-7@gated-at.bofh.it> |
| In reply to | #232374 |
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.
[toc] | [prev] | [next] | [standalone]
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | linux.debian.user
csiph-web