Re: [OFFTOPIC] Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems]
> 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]
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]
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]
> 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: Non-free firmware [was: Debian install Question]
Brian wrote: >On Thu 04 Mar 2021 at 11:40:00 -0600, David Wright wrote: > >> On Wed 03 Mar 2021 at 10:36:42 (-0500), rhkra...@gmail.com wrote: >> >> > It would be nicer if there was some person or group that tried to vet >> > them, or >> > maybe even suggesting that something like a requirement that at least one >> > other person attest that an installation image worked for them (on the >> > target >> > hardware). >> >> AIUI the Debian Install System Team build the Debian installer, and > >That's certainly correct. The effort put into this deserves to be better >appreciated. They provide a free installer of high quality. > >> the aforementioned Debian Images Team put it into the unofficial >> images, along with some extra .debs and a couple of Packages files. >> So I'm not sure I understand exactly what this person/group would >> be expected to vet. > >I am less sure that the Debian Images Team interact wih unofficial. >I'd be inclined to say that the conribution in unofficial is from a >DD, who may or not be part of the installer team. It is "unofficail" >after all. Time to set this straight, I think... I'm the team lead and main developer in the Debian Images Team (aka debian-cd), and I have been for many years now. *I* did the work to add the unofficial images that include non-free firmware. They're produced on the same machine as our official images, using the same software to build them. There's just some small config tweaks, that's all. In our team, we are ~always looking for more people to help, both for testing and development. We're a small group of volunteers, and we're all also busy doing other things in Debian too. This is the pattern for most Debian developers, in fact -- Steve McIntyre, Cambridge, UK.st...@einval.com "You can't barbecue lettuce!" -- Ellie Crane
Re: Una de discs durs
Sembla que la cosa s'ha arreglat. El problema radicava al cable d'alimentació. Amb la mateixa font, canviat de cable no han aparegut més errors. Gràcies a tots per la vostra aportació. Tingueu present el cas per si en un futur us passa. Toni Mas GPG 3F42A21D84D7E950 Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ En dissabte 27 de febrer de 2021 a les 13:56, Toni Mas Soler va escriure: > He permutat ports (per 2A vegada) > He canviat el cable (per 3a vegada) > I, novetat, he canviat el cable de corrent per un altre. > > Si això no funciona, miraré aquestes eines de diagnòstic a veure si em diuen > algo mes. > > Gràcies > > Sent from ProtonMail Mobile > > Actiu dl, febr 22, 2021 a 12:27, Alex Muntada va escriure: > > > Hola Toni > > > > > M'agradaria entendre el diagnòstic. Aquests valors que emfatitzes > > > són (aprox) així des del primer dia. Podria ser que estiguéssin > > > vinculats a la marca? > > > > Tens raó, podria ben bé ser que no siguin significatius. De fet, > > llegint la pàgina de la viquipèdia sobre l'SMART no marca aquests > > paràmetres com a indicadors de problemes al disc per la diferent > > implementació de cada fabricant: > > > > https://en.wikipedia.org/wiki/S.M.A.R.T.#Known_ATA_S.M.A.R.T._attributes > > > > Suposo que no estic acostumat a trobar-me valors WORST tan > > propers als THRESH i que no siguin errors. De totes formes, > > l'error del bus ATA té mala pinta, sobretot si se segueix > > produint, perquè indica un problema físic (disc, cable, > > controladora, memòria, etc.) no de programari. > > > > T'anava a dir que pots mirar d'actualitzar el firmware del disc > > per si es tracta d'un defecte de fabricació corregit en versions > > més noves, però veig que no n'hi ha pel teu número de sèrie. > > > > Potser val la pena provar a fer un diagnòstic del disc amb les > > eines del fabricant, ja que veig que Seagate té el SeaTools > > disponible per a linux: > > > > https://www.seagate.com/es/es/support/downloads/seatools/ > > > > Salut i gràcies per demanar més detalls, > > Alex > > > > -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Alex Muntada ⢿⡄⠘⠷⠚⠋ Debian Developer > > log.alexm.org ⠈⠳⣄ signature.asc Description: OpenPGP digital signature
Sharing a scanner from a Buster system
I have been trying for some time to setup a system that will share an attached scanner over the network. I had hoped to use Buster as it is still the stable instance of Debian. I have followed everything in [1] but I could never get it to work. I then tried Bullseye and it worked right away. Today I decided to install a clean NETINST image of each and repeat the "server" steps as outlined at [1]. Even though the howto states that it covers Debian from versions 8 to 11, I could not get it to work on Buster (10). The process failed on Buster, again, even though scanimage on the system saw the USB scanner (Epson Perfection 2480 Photo). I then installed Bullseye. The exact same process and the very same saned.conf file worked immediately. The client was the same in both cases (Buster). Is there a tweak that I am missing? Has there been a change that isn't in Buster but has made it to Bullseye? Any recommendations on debug steps would be appreciated? [1} https://wiki.debian.org/SaneOverNetwork#Sharing_a_USB_Connected_Scanner:_the_Basics -- Regards, John Boxall
Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems]
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
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
Blind and Low-Vision UNIX Users Group
Since I know we have some people on this list who might be interested in this -- https://blvuug.org/ is the home of the new Blind and Low-Vision UNIX Users Group. They're just getting started. -dsr-
Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems]
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]
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]
> 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: Non-free firmware [was: Debian install Question]
On Thursday, March 04, 2021 12:40:00 PM David Wright wrote: > On Wed 03 Mar 2021 at 10:36:42 (-0500), rhkra...@gmail.com wrote: > > On Tuesday, March 02, 2021 10:01:09 PM David Wright wrote: > Brian wrote: '"+1" for what? Advertising each and every non-Debian > installer that comes along and is uploaded to unofficial?' > > > > I was under the impression that "The Debian Images Team is a small > > > team of people working on creating, testing and distributing Debian > > > images for [us]", whereas you seem to be describing something like > > > a wiki where any Tom, Dick or Harry dumps their cobbled together > > > installer. > > > > Well, until and unless some person or group tries to vet those Debian > > installation images, that may be the best that can be done. > > You cut the context. > They wouldn't be "Debian installation images", > but "non-Debian installers", as quoted above. Ok. > > I don't want non-Debian installers on cdimage.debian.org, official > or unofficial. Do bear in mind that the debian-installer in the > official image is the same debian-installer as in the unofficial > image. The latter image just contains some extra files, almost > all of which originate from the kernel team or Debian. > > What I did suggest go into a wiki was the *method* of extracting > firmware from a particular driver. I notice that there is already > one fwcutter in my unofficial image (for Broadcom B54xx), but > I don't know how it works, nor whether it works in the same way > as one for the p54usb would. > > > It would be nicer if there was some person or group that tried to vet > > them, or maybe even suggesting that something like a requirement that at > > least one other person attest that an installation image worked for them > > (on the target hardware). > > AIUI the Debian Install System Team build the Debian installer, and > the aforementioned Debian Images Team put it into the unofficial > images, along with some extra .debs and a couple of Packages files. > So I'm not sure I understand exactly what this person/group would > be expected to vet. If there are non-free non-official Debian installers that add non-free firmware or such in order to install on specific hardware, the vetting would be to have someone else confirm that the install did indeed work on that hardware. Maybe I've confused this thread, but all that I'm trying to say is that: If: 1) the official Debian installer will not work on some hardware configurations, and 2) the only Debian installer listed on the main page of debian.org is that official one Then: 1) I'd like to see a (non-snarky) note on that main page that points out that installer may not work for everyone, and a little bit about why (hardware that doesn't have free drivers or firmware or such) and 2) it should include a link to some place (not necessarily the wiki you envision), and not necessarily on debian.org (but I think that would be good) to installers that work with various hardware configuraions that don't work with the official installer and 3) as mentioned above, it would be nice if those unofficial installers have been vetted by someone to confirm they indeed work on those hardware configurations.
Re: Non-free firmware [was: Debian install Question]
On Thu 04 Mar 2021 at 11:40:00 -0600, David Wright wrote: > On Wed 03 Mar 2021 at 10:36:42 (-0500), rhkra...@gmail.com wrote: > > > It would be nicer if there was some person or group that tried to vet them, > > or > > maybe even suggesting that something like a requirement that at least one > > other person attest that an installation image worked for them (on the > > target > > hardware). > > AIUI the Debian Install System Team build the Debian installer, and That's certainly correct. The effort put into this deserves to be better appreciated. They provide a free installer of high quality. > the aforementioned Debian Images Team put it into the unofficial > images, along with some extra .debs and a couple of Packages files. > So I'm not sure I understand exactly what this person/group would > be expected to vet. I am less sure that the Debian Images Team interact wih unofficial. I'd be inclined to say that the conribution in unofficial is from a DD, who may or not be part of the installer team. It is "unofficail" after all. -- Brian.
Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems]
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]
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: Non-free firmware [was: Debian install Question]
On Thu 04 Mar 2021 at 10:54:14 (+), Leandro neto wrote: > I volunteer to be [ ] a mirror on Rio de Janeiro Brasil. I build computers > but I don't know about programming leandro AIUI we're not talking about mirrors, but about building the software that might eventually be mirrored. Cheers, David.
Re: PARTIAL DIAGNOSIS of Installation problems
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.
Re: Non-free firmware [was: Debian install Question]
On Wed 03 Mar 2021 at 10:36:42 (-0500), rhkra...@gmail.com wrote: > On Tuesday, March 02, 2021 10:01:09 PM David Wright wrote: Brian wrote: '"+1" for what? Advertising each and every non-Debian installer that comes along and is uploaded to unofficial?' > > I was under the impression that "The Debian Images Team is a small > > team of people working on creating, testing and distributing Debian > > images for [us]", whereas you seem to be describing something like > > a wiki where any Tom, Dick or Harry dumps their cobbled together > > installer. > > Well, until and unless some person or group tries to vet those Debian > installation images, that may be the best that can be done. You cut the context. They wouldn't be "Debian installation images", but "non-Debian installers", as quoted above. I don't want non-Debian installers on cdimage.debian.org, official or unofficial. Do bear in mind that the debian-installer in the official image is the same debian-installer as in the unofficial image. The latter image just contains some extra files, almost all of which originate from the kernel team or Debian. What I did suggest go into a wiki was the *method* of extracting firmware from a particular driver. I notice that there is already one fwcutter in my unofficial image (for Broadcom B54xx), but I don't know how it works, nor whether it works in the same way as one for the p54usb would. > It would be nicer if there was some person or group that tried to vet them, > or > maybe even suggesting that something like a requirement that at least one > other person attest that an installation image worked for them (on the target > hardware). AIUI the Debian Install System Team build the Debian installer, and the aforementioned Debian Images Team put it into the unofficial images, along with some extra .debs and a couple of Packages files. So I'm not sure I understand exactly what this person/group would be expected to vet. Cheers, David.
Re: [HS] Outils de déploiement à la sauce wapt
Étrange, ils ne font pas mention de cette fin de support de la version communautaire sur leur site. Personnellement, j'utilise chocolatey https://chocolatey.org/ qui permet d'installer facilement des logiciels avec la commande "choco". Je crois qu'on peut également avoir ses propres repos qui sont au format NuGet. Olivier Le jeu. 4 mars 2021 à 10:34, David Martin a écrit : > Bonjour à tous, > > J'utilise wapt en version community sur mon infra pour déployer les postes > client, hors la version community va s'arréter. > > Est-ce que vous connaissez une solution similaire à utiliser ? > > > -- > david martin > >
OT: Bathroom scales (was: Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems])
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: Installation problems
Richard Owlett composed on 2021-03-04 05:54 (UTC-0600): > David Christensen wrote: >> I think 90% of the OP's problems stem from the fact that he does not >> have good Internet service. > I'm not aware of any germane issue with my internet service, nor with my > ISP. I suspect David was equating bad internet service with a data cap such as would cause one to purchase Debian media instead of downloading without having to consider a cap, as would I. > 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. it fails to install completely if using the netinst.iso . >5. the internet. I could have sworn you recently mentioned having two computers. :p I suppose this universe has from 0-1 TVs, none of which use Roku or Fire TV, or are a smart TV, to 'cut the "cable TV" cord'. Most of the newer models of these devices can use a wireless connection to an internet router, or a "hotspot", some only via wireless. I never needed wireless either, until I moved recently, into a house with TV cable ports in the wrong places that would cost big money to have relocated. I can't recall ever downloading a Debian DVD .iso. Usually I download only an installation linux and initrd.gz, not the similarly meager netinst.iso. Either way has usually worked for me on the first try for unstable, always first try for stable. I can only imagine frustration trying to install or keep updated using a capped internet connection. -- Evolution as taught in public schools, like religion, is based on faith, not on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems]
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]
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]
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]
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]
[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]
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: mounten SD-kaartje
Op 23-02-2021 om 21:17 schreef René Luijckx: Hoi, Ik gebruik een versie van Debian 9.13 ( stretch ). Het ( automatisch ) mounten van SD-kaartjes is normaal gesproken geen probleem. Ontkoppelen ditto. Echter . het mounten van micro-SD-kaartjes die in mijn camera hebben gezeten gaat slechts eenmalig. Ik sluit mijn laptop zelden af, klap hem dicht en hij gaat in slaapstand. In mijn camera zitten 2 SD kaartjes, per kaartje 1 soort foto's of video-bestanden. Beiden exfat geformateerd. exfat-utils is geïnstalleerd. Na een reboot kan ik beide kaartjes _eenmalig_ benaderen. Een heel enkele keer lukt het door te wisselen met een kaartje uit een andere machine ( fat16 ) toch een kaartje uit de camera te benaderen. Meestal echter niet. Ook in Gparted zijn de kaartjes dan niet te zien. Suggesties ? Ik ken gparted niet zo heel goed. Als het kaartje niet te zien is, is het dan wel zichtbaar met: fdisk -l ? Zo ja, dan is onderstaande misschien interessant: Het exfat filesysteem zit nog maar sinds kort in het Linux kernel. Daarvoor kon het alleen benaderd worden via fuse, wat misschien onbetrouwbaarder werkt. Exfat zit in Linux zelf sinds kernel 5.9 als ik me niet vergis (kan ook 5.8 zijn). Je hebt daarvoor dus minimaal een kernel uit buster-backports nodig. https://packages.debian.org/linux-image-amd64 Zo nee, dan wordt het hele kaartje niet gezien lijkt me. Misschien dat er bij de eerste keer verwijderen iets mis gaat? Misschien eerst netjes verwijderen? Misschien heb je er iets aan. Groet, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/
Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems]
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: Deb10 installer can't install grub
On Thu, Mar 04, 2021 at 08:09:46AM -0500, Greg Wooledge wrote: > to...@tuxteam.de (to...@tuxteam.de) wrote: > > > 1x 4TB, single drive, 3.7 TB, w=108MB/s , rw=50MB/s , > > > r=204MB/s > > > 2x 4TB, mirror (raid1),3.7 TB, w=106MB/s , rw=50MB/s , r=488MB/s > > > Thanks. Real data :) > > > > The doubling in read throughput is somewhat surprising to me. Some > > learning to do, it seems. > > There are two copies of everything. So, if you need to read a big > file, you can read half of it from disk 1 and the other half from disk 2, > roughly simultaneously. Makes sense, thanks. Cheers - t signature.asc Description: Digital signature
Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems]
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]
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: Deb10 installer can't install grub
to...@tuxteam.de (to...@tuxteam.de) wrote: > > 1x 4TB, single drive, 3.7 TB, w=108MB/s , rw=50MB/s , r=204MB/s > > 2x 4TB, mirror (raid1),3.7 TB, w=106MB/s , rw=50MB/s , r=488MB/s > Thanks. Real data :) > > The doubling in read throughput is somewhat surprising to me. Some > learning to do, it seems. There are two copies of everything. So, if you need to read a big file, you can read half of it from disk 1 and the other half from disk 2, roughly simultaneously.
Re: Installation problems
On 03/04/2021 06:27 AM, Tixy wrote: On Thu, 2021-03-04 at 05:54 -0600, Richard Owlett wrote: 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. Do you actually use the portability of the Alcatel Linkzone? If not (and I know things look easier in hindsight) perhaps you shouldn't have let them sell you it and bought a more suitable device, like a router with a 4G SIM slot. *ROFL**ROFL* I had an explicit requirement for portability. I had seen a device with the form factor of a USB flash drive which was effectively a modem for a cellular network. T-Mobile had the only competent salesman in the county. He recognized the device and why I would actively look for one. The closest he could come was the predecessor of my current device. Both devices were very satisfactory except the first failed in ~2 years. A quick search on Amazon shows your device for 54GBP and a TPLink 4G router [1] with 4 ethernet ports at 74GBP (prices with 20% sales TAX). You'd have to make sure what you bought worked with the variant of 4G your country/ISP uses, but I'm sure you could find out online what other people in your situation use. [1] https://www.amazon.co.uk/TL-MR6400-Unlocked-Configuration-Required-External/dp/B016ZWXYXG/
Re: [HS] Outils de déploiement à la sauce wapt
Merci pour vos retours, Pour wapt et son arrêt je savais d'ou ma question. Glpi nous utilisons, par contre le module dont tu parles je vais y jeter un coup d'œil. Merci encore Le jeu. 4 mars 2021 à 12:08, didier gaumet a écrit : > > Je serais bien en peine de te proposer des alternatives externes et > libres car ce genre d'outils m'est totalement étranger, désolé... > > Par contre, d'après le communiqué de la boîte qui développe wapt: >https://www.tranquil.it/wapt-community-changements-majeurs-2021/ > - la société stoppe le développement de wapt car elle estime que la > communauté ne participe pas assez à celui-ci mais est ouverte à un fork > amical, donc si ce fork voit le jour, le logiciel reste disponible sous > licence libre > - si utiliser un logiciel propriétaire ne te dérange pas, wapt discovery > devrait pouvoir remplacer wapt community sans surcoût puisqu'il sera > gratuit contrairement à wapt enterprise > > -- david martin
Re: PARTIAL DIAGNOSIS of Installation problems
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: Installation problems
On Thu, 2021-03-04 at 05:54 -0600, Richard Owlett wrote: >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. Do you actually use the portability of the Alcatel Linkzone? If not (and I know things look easier in hindsight) perhaps you shouldn't have let them sell you it and bought a more suitable device, like a router with a 4G SIM slot. A quick search on Amazon shows your device for 54GBP and a TPLink 4G router [1] with 4 ethernet ports at 74GBP (prices with 20% sales TAX). You'd have to make sure what you bought worked with the variant of 4G your country/ISP uses, but I'm sure you could find out online what other people in your situation use. [1] https://www.amazon.co.uk/TL-MR6400-Unlocked-Configuration-Required-External/dp/B016ZWXYXG/ -- Tixy
Re: Installation problems
On 03/03/2021 03:53 PM, Joe wrote:
On Wed, 3 Mar 2021 13:38:20 -0800
David Christensen wrote:
On 3/3/21 7:36 AM, Richard Owlett wrote:
On 03/03/2021 08:35 AM, David Christensen wrote:
On 3/3/21 1:24 AM, Richard Owlett wrote:
2. I'm pushing at my data cap {including unused from previous
months}.
Have you considered setting up a local package proxy server? I
used approx(8) in the past, and believe there are other choices:
https://packages.debian.org/buster/approx
I don't have a LAN of _any_ description. But do have plentiful disk
space. Might I be able to use something like apt-offline?
This is related to my recent reply to a fork of this thread. You
want a LAN. The residential gateways provided by internet service
providers typically include Wi-Fi and 4 Gigabit ports, which is
sufficient for a small LAN.
I think 90% of the OP's problems stem from the fact that he does not
have good Internet service.
I'm not aware of any germane issue with my internet service, nor with my
ISP.
In fact, I get the impression of dial-up.
I had only dial-up until about a decade ago. Still remember using an
acoustic coupler in the 70's ;/
I would expect that if he was able to acquire good Internet
connectivity, the cost would be far outweighed by the saving in IT
unpleasantness, and he would do so, and that therefore there is some
impediment.
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. it fails to install completely if using the netinst.iso .
5. the internet.
Re: Non-free firmware [was: Debian install Question]
I volunteer to beca mirror on Rio de Janeiro Brasil. I build computers but I don't know about programming leandro Enviado via UOL Mail _ Assunto: Re: Non-free firmware [was: Debian install Question] De: rhkra...@gmail.com Enviado em: 3 de março de 2021 12:37 Para: debian-user@lists.debian.org On Tuesday, March 02, 2021 10:01:09 PM David Wright wrote: > I was under the impression that "The Debian Images Team is a small > team of people working on creating, testing and distributing Debian > images for [us]", whereas you seem to be describing something like > a wiki where any Tom, Dick or Harry dumps their cobbled together > installer. Well, until and unless some person or group tries to vet those Debian installation images, that may be the best that can be done. It would be nicer if there was some person or group that tried to vet them, or maybe even suggesting that something like a requirement that at least one other person attest that an installation image worked for them (on the target hardware).
Re: [HS] Outils de déploiement à la sauce wapt
Je serais bien en peine de te proposer des alternatives externes et libres car ce genre d'outils m'est totalement étranger, désolé... Par contre, d'après le communiqué de la boîte qui développe wapt: https://www.tranquil.it/wapt-community-changements-majeurs-2021/ - la société stoppe le développement de wapt car elle estime que la communauté ne participe pas assez à celui-ci mais est ouverte à un fork amical, donc si ce fork voit le jour, le logiciel reste disponible sous licence libre - si utiliser un logiciel propriétaire ne te dérange pas, wapt discovery devrait pouvoir remplacer wapt community sans surcoût puisqu'il sera gratuit contrairement à wapt enterprise
Re: Non-free firmware [was: Debian install Question]
On 2021-03-03, rhkra...@gmail.com wrote: > On Tuesday, March 02, 2021 10:01:09 PM David Wright wrote: >> I was under the impression that "The Debian Images Team is a small >> team of people working on creating, testing and distributing Debian >> images for [us]", whereas you seem to be describing something like >> a wiki where any Tom, Dick or Harry dumps their cobbled together >> installer. > > Well, until and unless some person or group tries to vet those Debian > installation images, that may be the best that can be done. > > It would be nicer if there was some person or group that tried to vet them, > or > maybe even suggesting that something like a requirement that at least one > other person attest that an installation image worked for them (on the target > hardware). It's when you don't know what you don't know that you need to know it.
Re: Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems]
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]
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
[HS] Outils de déploiement à la sauce wapt
Bonjour à tous, J'utilise wapt en version community sur mon infra pour déployer les postes client, hors la version community va s'arréter. Est-ce que vous connaissez une solution similaire à utiliser ? -- david martin
Re: Deb10 installer can't install grub
Dave Sherohman writes: > Any tips on making use of the grub shell to make further progress, such > as getting the system to boot in non-rescue mode (i.e., not chrooted > from the installer)? The help information available in the grub shell > itself isn't terribly useful because it scrolls off the screen with no > (obvious) pager or scrollback buffer. There is a pager in Grub but it really isn't obvious. For the future it's enabled by set pager=1. Why it's not on by default I don't know...
Re: Deb10 installer can't install grub
On Wed, Mar 03, 2021 at 05:40:39PM -0500, Dan Ritter wrote: > Felix Miata wrote: > > Andrei POPESCU composed on 2021-03-03 17:50 (UTC+0200): > > > > > Felix Miata wrote: > > [...] Do > > you know of, or can you provide a reference to, any way RAID1 performance > > can be > > better than single disk? > > Sure. > > https://calomel.org/zfs_raid_speed_capacity.html > > First two lines of the first table of results: > > 1x 4TB, single drive, 3.7 TB, w=108MB/s , rw=50MB/s , r=204MB/s > 2x 4TB, mirror (raid1),3.7 TB, w=106MB/s , rw=50MB/s , r=488MB/s > > Which is as theory predicts: slight reduction in write > performance (write being dominated by disk cache -> disk, not > system -> disk cache), and approximate doubling in read > performance. Thanks. Real data :) The doubling in read throughput is somewhat surprising to me. Some learning to do, it seems. Cheers - t signature.asc Description: Digital signature
Re: Deb10 installer can't install grub
On Wed, Mar 03, 2021 at 05:16:14PM -0500, Felix Miata wrote: > Andrei POPESCU composed on 2021-03-03 17:50 (UTC+0200): > > > Felix Miata wrote: > > >> To start with, RAID1 is marginally slower than ordinary filesystems on > >> partitions. > > > This is true for some workloads, for others it can be significantly > > faster. > > > https://arstechnica.com/information-technology/2020/04/understanding-raid-how-performance-scales-from-one-disk-to-eight/ > > [...] Do > you know of, or can you provide a reference to, any way RAID1 performance can > be > better than single disk? I can just provide a hint: when accessing mirrored disks, reading is done whenever the first disk finishes; writing whenever both disks are done. So reading is potentially faster, writing potentially slower. That's about latency. The throughput shouldn't change too much (unless you're combining very different disks, but that'd be asking for it). Compose this with several layers of buffering and I doubt you'll be able to make out any significant difference though. No experimental data to back this up, alas. > Evolution as taught in public schools, like religion, > is based on faith, not on science. OK. Now all bets wrt RAID are off, anyway. Cheers - t signature.asc Description: Digital signature
Re: PARTIAL DIAGNOSIS of Installation problems
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
Re: [resolu] Re: apt pinning: j'y comprends rien !
Je pense que ta configuration tombe en marche par accident mais risque de ne pas fonctionner pas dans d'autres cas moins spécifiques ;-) - firefox et firefox-l10n* sont des paquets qui n'existent que dans le dépôt unstable (j'ai pas vérifié, je suppose qu'il n'est pas non plus empaqueté chez Marillat) - c'est firefox-esr et firefox-esr-l10n* qui figurent dans les autres dépôts Debian - donc dans ce cas précis les priorités n'ont pas une grosse importance Contre-exemple: prends le paquet linux-image-amd64 et supposons que pour ce paquet spécifique tu souhaites suivre unstable plutôt que testing. Il est à l'heure actuelle en 5.10.13 en testing et 5.10.19 en unstable. Si tu adoptes le même paramétrage que celui que tu as adopté pour Firefox, tu vas rester avec le 5.10.13 de testing :-)
Trusting trust [was: PARTIAL DIAGNOSIS of Installation problems]
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: apt pinning: j'y comprends rien !
Le 04/03/2021 à 00:52, Gaëtan Perrier a écrit : Moi je veux l'inverse: que ceux de dmo ne soient pas prioritaires par rapport à testing Debian (sauf pour quelques paquets). Justement non, ce n'est pas l'inverse :-) Toujours rapporté à l'exemple précédent, pour ce que tu souhaites, tu dois définir deux choses distinctes: - en début de fichier des préférences spécifiques avec des priorités 900installer - en fin de fichier des préférences génériques avec des priorités 0ceux-ci ne soient installés *que* lorsqu'ils constituent des dépendances absolument nécessaires d'autres paquets que tu souhaites installer.
