Re: fw_update
On 2024-05-03, Harald Dunkel wrote: > On 2024-05-02 21:25:00, Stuart Henderson wrote: >> >> You have an old fw_update(1) manual lying around which should be >> removed. It moved to fw_update(8). >> > > "Moved"? Yes. It used to be in section 1, it has moved to section 8. Unless you remove the extra file, man(1) will by default show the obsolete section 1 manual.
Re: fw_update
On 2024-05-02 21:25:00, Stuart Henderson wrote: You have an old fw_update(1) manual lying around which should be removed. It moved to fw_update(8). "Moved"? And yet another BTW: https://man.openbsd.org/OpenBSD-7.5/ seems to be forgotten. Regards Harri
Re: fw_update
On 2024-05-02, Harald Dunkel wrote: > On 2024-04-30 13:25:39, Страхиња Радић wrote: >> Дана 24/04/30 01:12PM, Kirill A. Korinsky написа: >>> You may download it by hand and install as fw_update /path/to/firmware.tgz >> >> BTW, this is in fw_update(8). >> >> man 8 fw_update >> /SYNOPSIS >> > > Another BTW: > > # fw_update -i > fw_update: unknown option -- -i > usage: fw_update [-adFnv] [-p path] [driver | file ...] > > The man page says > > SYNOPSIS >fw_update [-adinv] [-p path] [driver ...] > > What is -F supposed to do? What happened to the -i? You have an old fw_update(1) manual lying around which should be removed. It moved to fw_update(8). -- Please keep replies on the mailing list.
Re: fw_update
Дана 24/05/02 02:55PM, Harald Dunkel написа: > SYNOPSIS >fw_update [-adinv] [-p path] [driver ...] > > What is -F supposed to do? What happened to the -i? I'm not sure what flavor are you using, but you should update it and the packages (type ‘pkg_add -u’ as root). With OpenBSD 7.5 release: $ man 8 fw_update ... SYNOPSIS fw_update [-adFnv] [-p path] [driver | file ...] ... -F Download firmware only. By default downloads to the current directory. Specifying a URL with -p downloads from that URL, specifying a path downloads to that directory. ... OpenBSD 7.5 March 9, 2022...
Re: fw_update
On Thu, May 02, 2024 at 02:55:33PM +0200, Harald Dunkel wrote: > On 2024-04-30 13:25:39, ?? wrote: > > 24/04/30 01:12PM, Kirill A. Korinsky : > >> You may download it by hand and install as fw_update /path/to/firmware.tgz > > > > BTW, this is in fw_update(8). > > > > man 8 fw_update > > /SYNOPSIS > > > > Another BTW: > > # fw_update -i > fw_update: unknown option -- -i > usage: fw_update [-adFnv] [-p path] [driver | file ...] > > The man page says > > SYNOPSIS >fw_update [-adinv] [-p path] [driver ...] > > What is -F supposed to do? What happened to the -i? > hi. i think your document is out of date, though i'm not sure what you're running exactly. if you look online: man.openbsd.org/fw_update.8 (that matches what i have here on amd64 -current) -F is documented and -i is not. jmc
Re: fw_update
On 2024-04-30 13:25:39, Страхиња Радић wrote: Дана 24/04/30 01:12PM, Kirill A. Korinsky написа: You may download it by hand and install as fw_update /path/to/firmware.tgz BTW, this is in fw_update(8). man 8 fw_update /SYNOPSIS Another BTW: # fw_update -i fw_update: unknown option -- -i usage: fw_update [-adFnv] [-p path] [driver | file ...] The man page says SYNOPSIS fw_update [-adinv] [-p path] [driver ...] What is -F supposed to do? What happened to the -i?
Re: fw_update
> How does fw_update install the drivers? > How does it know which driver is missing on the system? Just list the following sequence (outputs inserted too): $ which fw_update /usr/sbin/fw_update $ cat /usr/sbin/fw_update #!/bin/ksh # $OpenBSD: fw_update.sh,v 1.56 2024/03/21 01:02:29 afresh1 Exp $ [ ... ] You can see the file for many "utilities", i.e. pkg_* suite too. Some are shell scripts, some are perl scrips or maybe other interpreted languages. Some are binary. fw_update is done as a shell script.
Re: fw_update
Дана 24/04/30 01:12PM, Kirill A. Korinsky написа: > You may download it by hand and install as fw_update /path/to/firmware.tgz BTW, this is in fw_update(8). man 8 fw_update /SYNOPSIS
Re: fw_update
On Tue, 30 Apr 2024 12:35:17 +0200, fr...@lilo.org wrote: > > How does fw_update install the drivers? It downloads firmware from http://firmware.openbsd.org/firmware/ and installs it as package in system. > How does it know which driver is missing on the system? It checks patterns from /usr/share/misc/firmware_patterns which maps firmware to a pattern in dmesg. > All these questions to install the drivers manually (offline) You may download it by hand and install as fw_update /path/to/firmware.tgz -- wbr, Kirill
Re: fw_update
Hello, Firmwares aren't drivers per say they are required along with the driver Chris Sent from Proton Mail Android Original Message On 4/30/24 5:35 AM, wrote: > How does fw_update install the drivers? > How does it know which driver is missing on the system? > All these questions to install the drivers manually (offline) > > Tks > > > >
Re: fw_update issue with colon in URL
‐‐‐ Original Message ‐‐‐ On Wednesday, July 15, 2020 12:49 PM, Theo Buehler wrote: > One server had an incorrect config. This should be fixed now. Thanks for your notification, so I didn't go mad ;) I can confirm, it works like a charm. Thanks again for fixing!
Re: fw_update issue with colon in URL
On Tue, Jul 14, 2020 at 07:57:35PM +, mabi wrote: > Hello, > > I just updated from 6.6 to 6.7 and the fw_update part failed so I tried to > run it manually and get: > > $ sudo fw_update -n > http://firmware.openbsd.org/firmware/6.7/: no such dir > Couldn't find updates for intel-firmware-20191115v0 One server had an incorrect config. This should be fixed now.
Re: fw_update issue with colon in URL
On 15/7/20 5:57 am, mabi wrote: > http://firmware.openbsd.org/firmware/6.7/: no such dir > Couldn't find updates for intel-firmware-20191115v0 > > It looks like I have a colon ":" at the end of the URL which of course makes > the URL invalid. Now how could this happen? and in which file do I fix that? That's just a separator in the output, not in the URL. : hth
re: fw_update verify firmware?
> This has nothing to do with OpenBSD. If OpenBSD would have a switch to disable usage of all BLOBs provided by OBSD at once on an user desire. Does OpenBSD have any other BLOBs except firmwares which can be deleted/renamed/moved? > Please read your own statement. You aren't qualified to assert your opinion in this group, humble or not. He does not assert, but rather trying to find a truth which is very difficult in a security area because most agencies trying to hide such info and even often promote intentional misleading false on this topic. > It's not our job to turn you into a security expert. Nobody's trying to force you to share knowledge, it is on your own will, up to you. If someone else would ask that questions would you take it easier? > If you value the work that OpenBSD does to protect your security, use it. > If you don't, use something else. As it is obvious from a discussion he still evaluating OpenBSD, that is the reason of his many questions. > Please. We aren't here to win you over. Actually it does not matter for him win you him or not, he just wants to make a good choice, though it seems there is no other variants for him except paid grsec + his time spent on hardening the whole installation with grsec. Btw, an idea of hardening processes by their own declaration like unveil, pledge, etc. looks very nice. >Some of us are kinda tired of your flood of queries asking for yet another >opinion on often and widely discussed topics. It is very hard times now when shameless corporations attack single persons, thanks for understanding, he is his line of defense. > ...and you won't find much modern hardware that it works on. He does NOT need much hardware also he does NOT need modern hardware and he does NOT need a shiny superfast desktop. Very slow secure OS on a very slow ancient hardware which can protect him is many many times better than any modern super expensive server if it would be even a free gift. > Oh, btw...if I recall properly, a lot of CPU security fixes are > distributed as firmware microcode updates that have to be loaded by the > OS. So... being inappropriately paranoid about firmware could compromise > your security. Especially if new backdoors (e.g. for rooting CPUs) are added in new microcode versions? He does not trust any modern X86 CPUs with a firmware update or not. May be using a full software emulator can improve security? Say if running a very slow full software emulation of a rare CPU like Motorolla or MIPS on Librebooted X86 CPU host like Core2 QUAD 9500 or something like it, would it be more secure inside a emulated MIPS guest to run OpenBSD than on a bare metal X86?
Re: fw_update verify firmware?
Aaron Mason wrote: > On Fri, May 15, 2020 at 3:39 AM Nick Holland > wrote: > > > > On 2020-05-14 11:08, i...@aulix.com wrote: > > > > I actually had Adaptec give me a firmware update with a time bomb in > > it, and didn't bother to tell me that after X days, it would brick my > > adapter and prevent me from updating/downdating it. If it had been > > stored in RAM, I might have been able to recover it, but since it was > > flashed into EEPROM and prevented the machine from booting, the card > > had to be replaced...and my customer had an outage. > > Apropos of nothing, that saga is worth reading in full: > > Episode 4: A New Flaw - http://marc.info/?l=openbsd-misc&m=125783114503531&w=2 > Episode 5: The Firmware Strikes Back: > http://marc.info/?l=openbsd-misc&m=126775051500581&w=2 > Episode 6: Return of the Vendor: > http://marc.info/?l=openbsd-misc&m=128779369427908&w=2 NO. it is completely UNRELATED to the subject which is about fw_update fw_update does NOT update controller firmware on that device.
Re: fw_update verify firmware?
On Fri, May 15, 2020 at 3:39 AM Nick Holland wrote: > > On 2020-05-14 11:08, i...@aulix.com wrote: > > I actually had Adaptec give me a firmware update with a time bomb in > it, and didn't bother to tell me that after X days, it would brick my > adapter and prevent me from updating/downdating it. If it had been > stored in RAM, I might have been able to recover it, but since it was > flashed into EEPROM and prevented the machine from booting, the card > had to be replaced...and my customer had an outage. Apropos of nothing, that saga is worth reading in full: Episode 4: A New Flaw - http://marc.info/?l=openbsd-misc&m=125783114503531&w=2 Episode 5: The Firmware Strikes Back: http://marc.info/?l=openbsd-misc&m=126775051500581&w=2 Episode 6: Return of the Vendor: http://marc.info/?l=openbsd-misc&m=128779369427908&w=2 -- Aaron Mason - Programmer, open source addict I've taken my software vows - for beta or for worse
Re: fw_update verify firmware?
On Thu, May 14, 2020 at 04:25:11AM +, Mogens Jensen wrote: > I was just trying out the fw_update program on OpenBSD 6.5, deleting/ > installing all the firmware and was wondering if fw_update will verify > the files before installing? Others pointed out that firmwares are signed. For a while now, fw_update AND pkg_add have defaulted to requiring signed packages. If you try to install or even peek at something unsigned with pkg_info, they error out. You have to explicitly ask for unsigned data to bypass the check.
Re: fw_update verify firmware?
Nick Holland wrote: > On 2020-05-14 11:08, i...@aulix.com wrote: > >> If that binary code was on a ROM, would it be less malicious? > > > > Cannot more recent and up to date binary code be more malicious than > > old one in the ROM? > > This has nothing to do with OpenBSD. That can be true for any kind of > code update, whether it exists in RAM on a device that's loaded by the > OS at boot time, EEPROM that can be reprogrammed by software, or a > chip that has to be physically swapped out. > > I actually had Adaptec give me a firmware update with a time bomb in > it, and didn't bother to tell me that after X days, it would brick my > adapter and prevent me from updating/downdating it. If it had been > stored in RAM, I might have been able to recover it, but since it was > flashed into EEPROM and prevented the machine from booting, the card > had to be replaced...and my customer had an outage. That is completely unrelated to the signed-firmwares which OpenBSD distributes. And we don't have a firmware for Adaptec raid controllers. These kinds of off-topic additions to stupid conversations don't help to unstupid the conversations.
Re: fw_update verify firmware?
On 2020-05-14 11:08, i...@aulix.com wrote: >> If that binary code was on a ROM, would it be less malicious? > > Cannot more recent and up to date binary code be more malicious than > old one in the ROM? This has nothing to do with OpenBSD. That can be true for any kind of code update, whether it exists in RAM on a device that's loaded by the OS at boot time, EEPROM that can be reprogrammed by software, or a chip that has to be physically swapped out. I actually had Adaptec give me a firmware update with a time bomb in it, and didn't bother to tell me that after X days, it would brick my adapter and prevent me from updating/downdating it. If it had been stored in RAM, I might have been able to recover it, but since it was flashed into EEPROM and prevented the machine from booting, the card had to be replaced...and my customer had an outage. > Please take into account, I am a very noob in security area and it is > just my IMHO. Please read your own statement. You aren't qualified to assert your opinion in this group, humble or not. It's not our job to turn you into a security expert. If you value the work that OpenBSD does to protect your security, use it. If you don't, use something else. Please. We aren't here to win you over. Some of us are kinda tired of your flood of queries asking for yet another opinion on often and widely discussed topics. > Anyway there was another distro like LibertyBSD which was an OpenBSD > without some already seldom blobs like firmwares. And another OpenBSD > fork is declared to be going to appear: Hyperbola (it is Linux based > yet for now), completely pure from BLOBs too. ...and you won't find much modern hardware that it works on. You can achieve your goal (including the "not working on your hardware" feature) with OpenBSD by just removing the contents of the /etc/firmware directory. If the firmware isn't needed on your machine. it's not loaded. Concern about firmware binaries is not incorrect, but it is horribly missing a lot of points about how modern computers work. It's kinda like putting six bullets in a revolver, and obsessing about the third one. Yes, sure...that third one may blow a hole in your head or protect you from the rabid wolf, but the other five could do very much the same. And in most cases, you have far bigger security concerns than malicious firmware. Here's a free security lesson: If I want to take control of your machine, I'll use the easiest route; that won't be malicious firmware. Oh, btw...if I recall properly, a lot of CPU security fixes are distributed as firmware microcode updates that have to be loaded by the OS. So... being inappropriately paranoid about firmware could compromise your security. Nick.
Re: fw_update verify firmware?
i...@aulix.com wrote: > > If that binary code was on a ROM, would it be less malicious? > > Cannot more recent and up to date binary code be more malicious than old one > in the ROM? Our firmwares do not replace code on ROM, since the hardware in question HAS NO ROM.
Re: fw_update verify firmware?
> If that binary code was on a ROM, would it be less malicious? Cannot more recent and up to date binary code be more malicious than old one in the ROM? Just because backdoor development is progressing as time goes and old backdoors may be less dangerous compared to modern ones? > If the binary code is malicious, don't buy the hardware it is > associated with. Often there is no other choice except taking the oldest hardware we can afford to find. Please take into account, I am a very noob in security area and it is just my IMHO. Anyway there was another distro like LibertyBSD which was an OpenBSD without some already seldom blobs like firmwares. And another OpenBSD fork is declared to be going to appear: Hyperbola (it is Linux based yet for now), completely pure from BLOBs too.
Re: fw_update verify firmware?
Janne Johansson wrote: > Den tors 14 maj 2020 kl 06:27 skrev Mogens Jensen < > mogens-jen...@protonmail.com>: > > > Normally I would just assume that fetched files are verified, but maybe > > in the case with fw_update, the rationale is that firmware files are > > binary blobs so we can't know if they are malicious anyway, therefore > > no reason to bother with verification. > > > > It would be sad to mixup the fact that something is signed with a sort of > guarantee that it is without faults or without malice. > The signature proves it didn't change in transport since it was published, > nothing more. There is nothing malicious about the firmware blobs. It is the binary code for the cpus on the hardware. If that binary code was on a ROM, would it be less malicious? If the binary code is malicious, don't buy the hardware it is associated with. The code is not what makes it malicious. That line of thought is complete bullshit.
Re: fw_update verify firmware?
On 2020-05-14, Mogens Jensen wrote: > I was just trying out the fw_update program on OpenBSD 6.5, deleting/ > installing all the firmware and was wondering if fw_update will verify > the files before installing? > > There is a SHA256.sig in the remote firmware directory, but no > indication from fw_update, even with verbose output, if this is > actually used. SHA256.sig is not used here. The firmware files are in the standard package format: a specially constructed tar.gz with an embedded signature in the gzip comment. See pkg_sign(8) for more information. > Normally I would just assume that fetched files are verified, but maybe > in the case with fw_update, the rationale is that firmware files are > binary blobs so we can't know if they are malicious anyway, therefore > no reason to bother with verification. As with any other package that can install files and execute commands on your system, malicious firmware packagss would be a big problem. The signature checking is important. > As firmware is fetched over plain HTTP, I guess that in case of no > verification it would in theory make the system vulnerable to a MITM > attack, but I'm no expert. It's vulnerable to a "serve stale content" attack, i.e. sticking to an older version with vulnerabilities when a fixed version is available. But someone who can do that can also just block access to the update servers having the same end result. These can probably be mitigated by adding firmware packages to the table of vulnerable package versions in the "quirks" package in the main package set (though if that is also held back, it relies on the user to notice via the displayed timestamp, I don't hold out much hope for this really being noticed. We could make this more visible by having the quirks packages "expire" but this has problems too, especially for architectures which take a long time to build packages, or which don't have binary packages for -stable). As the firmware servers are independent and run by different people under one domain name they can't really share a private key, making it awkward to obtain certificates. Not impossible, we know how to do it using DNS-01 and copying CSRs amd certificates around, but I'm not really seeing enough benefits from running https on them to make it worthwhile.
Re: fw_update verify firmware?
Den tors 14 maj 2020 kl 06:27 skrev Mogens Jensen < mogens-jen...@protonmail.com>: > Normally I would just assume that fetched files are verified, but maybe > in the case with fw_update, the rationale is that firmware files are > binary blobs so we can't know if they are malicious anyway, therefore > no reason to bother with verification. > It would be sad to mixup the fact that something is signed with a sort of guarantee that it is without faults or without malice. The signature proves it didn't change in transport since it was published, nothing more. -- May the most significant bit of your life be positive.
Re: fw_update verify firmware?
The firmwares are packages, and are signed with the /etc/signify/openbsd-XX-fs.pub key. There is no risk. Mogens Jensen wrote: > I was just trying out the fw_update program on OpenBSD 6.5, deleting/ > installing all the firmware and was wondering if fw_update will verify > the files before installing? > > There is a SHA256.sig in the remote firmware directory, but no > indication from fw_update, even with verbose output, if this is > actually used. > > After looking at the source and manpage of fw_update, it was still not > clear to me if files are checked against SHA256.sig. For syspatch, it's > easy to tell from both source, manpage and program output. > > Normally I would just assume that fetched files are verified, but maybe > in the case with fw_update, the rationale is that firmware files are > binary blobs so we can't know if they are malicious anyway, therefore > no reason to bother with verification. > > As firmware is fetched over plain HTTP, I guess that in case of no > verification it would in theory make the system vulnerable to a MITM > attack, but I'm no expert. > > > Regards, > Mogens Jensen >
Re: fw_update long timeout, how to specify mirror
On 22/10/2019 18.01, Theo de Raadt wrote: The firmwares are intentionally kept out of the standard download zone. I'll talk to some people and see if there is a way we can shift things around, to make slight improvements. However, I don't see how anything we do would fix your problem. Whatever new other storage location we select, it won't contain the files you need, because you would not have copied the entire pile of firmwares to that place. I do have a mirror of firmware.openbsd.org and it works if I specify the location with fw_update -p http://mymirror.lol/openbsd/firmware/6.6/ This leads me to believe that if there was a question about firmware mirror in the installer and an "/etc/firmwareurl" or some such it would solve the problem with the sysupgrade as well. Until then the DNS hack would be the ugly work around as Claus suggested. /T
Re: fw_update long timeout, how to specify mirror
Tommy Nevtelen [to...@nevtelen.com] wrote: > Hi! > > I have some systems without access to the Internets and with internal > mirrors for packages and fw_update packages. But when openbsd does a > sysupgrade or a new install it runs fw_update against firmware.openbsd.org. > The problem here is that it will hang until the timeout is reached. If your case is like mine, you have a management network with zero internet access. But you might also have a machine which can be setup to bridge the gap, with a proxy. The ftp client which does the actual file transfer honors the "http_proxy" environment variable so you can do something like: export http_proxy=http://my.proxy.server:1234/
Re: fw_update long timeout, how to specify mirror
Tommy Nevtelen wrote: > I have some systems without access to the Internets and with internal > mirrors for packages and fw_update packages. But when openbsd does a > sysupgrade or a new install it runs fw_update against > firmware.openbsd.org. The problem here is that it will hang until the Maybe map firmware.openbsd.org to your internal mirror? How to do that depends on your DNS setup. -- Address is valid for this mailing list only.
Re: fw_update long timeout, how to specify mirror
Tommy Nevtelen wrote: > I have some systems without access to the Internets and with internal > mirrors for packages and fw_update packages. But when openbsd does a > sysupgrade or a new install it runs fw_update against > firmware.openbsd.org. The problem here is that it will hang until the > timeout is reached. Yes, quite unfortunate. > # time fw_update > http://firmware.openbsd.org/firmware/6.6/: ftp: connect: No route to host > http://firmware.openbsd.org/firmware/6.6/: empty > Couldn't find updates for intel-firmware-20190514p0v0 vmm-firmware-1.11.0p1 > 5m04.55s real 0m00.36s user 0m02.30s system > > We are able to do "fw_update -p" but is there a way to change it in > sysupgrade or at new installs (we do use siteXX.tgz). It's not using > /etc/installurl :( The firmwares are intentionally kept out of the standard download zone. I'll talk to some people and see if there is a way we can shift things around, to make slight improvements. However, I don't see how anything we do would fix your problem. Whatever new other storage location we select, it won't contain the files you need, because you would not have copied the entire pile of firmwares to that place.
Re: fw_update signify unsigned package on current and 6.2-stable -SOLVED
-Original Message- From: Theodore Wynnychenko Sent: Wednesday, November 01, 2017 8:43 AM To: misc@openbsd.org Subject: fw_update signify unsigned package on current and 6.2-stable Hello: How do I install the iwm-firmware without a network connection on either 6.2-stable or -current? Thanks Ted I just wanted to say thank you to Nigel Taylor who sent some advice off list. I don't know how I f...ed up, but the problem was one of my own doing apparently (somehow, I had downloaded install media and firmware that were out of sync, and did not realize I had done so). So, after purging and then re-downloading the correct files, everything "just worked." Sorry for the noise.
Re: fw_update stops with Fatal error: Unsigned package ...
On 2016-10-03 14:11, Mihai Popescu wrote: I've installed a snapshot somewhile ago, then I needed to update the firmware for athn device. I get this error: # fw_update UNSIGNED PACKAGES: athn-firmware-1.1p1 Fatal error: Unsigned package http://firmware.openbsd.org/firmware/snapshots/athn-firmware-1.1p1.tgz at /usr/libdata/perl5/OpenBSD/PkgAdd.pm line 717. As you can see from dmesg, I have other firmare needed hardware installed, but theirs firmware was loaded at first boot with no problem then. What is a way to get the proper firmware installed, please? OpenBSD 6.0-current (GENERIC.MP) #2432: Sat Sep 10 14:06:57 MDT 2016 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP [snip] Update your snapshot. Packages (including firmware) use a new signing methodology. http://marc.info/?l=openbsd-tech&m=147283361813517&w=2
Re: fw_update
* David Coppa [2012-05-09 23:40]: > If you have concerns with firmwares, swap your card with, for example, an > atheros or another card that doesn't need a firmware. wait. on those cards, the firmware is simply on the card itself, usually in some kind of flash. where's the difference really? the difference is that in one case the firmware is stored on the card, in the other case it has to be uploaded to the card by the OS. now that makes a huge difference for privacy et al... -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re : Re: Re : Re: fw_update
I confirm it works, so this firmware (athn,uvideo) is not necessary. My network card is an Atheros AR9285. I suspect it could have been my Atheros too Bluetooth Adapter. Call me paranoid but it makes me happier! I apologize for the bad format of my last email (new webmail) and some out-of-topic comments. I think I was in evangelic mode.. Sorry. Last question. Which is the best way to disable fw_update so that when it connects to the network it doesnB4t attempt to install more firmware? Stuart suggested: # echo 127.0.0.1 firmware.openbsd.org >> /etc/hosts will this work if I have another source other than ftp.openbsd.org? ie. are the firmware updates independent from the pkg source? I'd like to round up with a request to make firmware installation optional in the installer (amd64 cd) if there are any chances that the OS will work without it. Some question like: "Would you like to install X (your Z hardware might not be operative without it)". This would me happier too. Thanks for your patience and work. > - Message d'origine - > De : David Coppa > EnvoyC)s : 10.05.12 12:20 > C : mark sullivan > Objet : Re: Re : Re: fw_update > > On Thu, May 10, 2012 at 12:03 PM, mark sullivan wrote: > > I didn't even have the chance to test if it would work without it. > > Yes, it should work. > > Just remove the package with "pkg_delete athn-firmware".
Re: fw_update
On Wed, May 9, 2012 at 3:33 PM, mark sullivan wrote: > I would like to hear your arguments on this and if there is a simple way > to disable fw_update and uninstall in general everything propietary > affecting the network card that I have not been warned about. I read on the > FAQ that I should have been asked about this firmware but I wasnB4t! (amd64 > cd installer). > are you confusing "proprietary" with "third-party"? the firmware you're concerned about is provided by the card's manufacturer (or the chipset manufacturer) and the card (or chip) won't work without it. the reason OpenBSD needs to download it is because the manufacturer won't allow OpenBSD to include it on the CD. if you don't download it, the device won't work -- if the device could work effectively without it, OpenBSD would not go to the trouble of downloading it to begin with. this is not the same thing as third-party firmware which replaces the manufacturer's firmware. examples of this kind of thing are OpenWRT and Tomato firmware which replace the factory firmware on certain consumer-grade routers. -ken
Re: fw_update
On Thu, May 10, 2012 at 10:34:14AM +1000, Brett wrote: > > Easiest way to disable the uvideo firmware (and any bios video spyware) is to > stick black electrical tape over the webcam lens. > When I was a kid, one of the science experiments we did was to use a speaker as a microphone. Electrical tape clearly wouldn't work here. Get out your soldering iron. Anyway, my personal paranoid favorite is that here in the Austin Texas area, they have helpful traffic cameras for adjusting traffic flow that do not point upwards at traffic to be adjusted for, but point directly at face and license plates. Scary Huh. Theo's advice to leave the country seems appropriate. Enough paranoia. ;(
Re: fw_update
>Also, while I recognize this is an edge case, I have in the past sold >systems with OpenBSD installed on them to other people, and now that I >come to think of it I have no idea whether that's legal to do with, say, >iwn-firmware installed on it (it's probably not). Every firmware package includes a *-license file which is installed next to the firmware in /etc/firmware Read that file. Decide for yourself, rather than posting dribble. But let's get back to this selling and legalicy thing. You may be aware that the rest of OpenBSD comes with a source tree populated with statements about no warranty, implied or not. If you sell it, it is your problem. If you expect me to protect you -- someone mailing from a .us address -- from getting sued, you are completely out of your freaking mind. If you don't like that, move to another country.
Re: Re : Re: fw_update
My advice is to not use a computer at all. Stick to pen and paper. P.S. You are a fucking stupid fucking moron. I would suggest that you fashion a hat out of aluminum foil and wear it firmly on your head. This way you will stop wasting the time of rational people. On Thu, May 10, 2012, at 12:03 PM, mark sullivan wrote: > >>>If you have concerns with firmwares, swap your card with, for example, an > >>>atheros or another card that doesn't need a firmware. > >> Some atheros does use firmware, eg athn(4). > >Not all the athns. Only USB ones, like the AR9271, need a firmware. > Mine is an Atheros (athn, I don't know the model now sorry), not USB and > OpenBSD automatically installed athn-firmware-1.1p0. I didn't even have > the chance to test if it would work without it. This is the point of my > complaint. I would have expected OpenBSD to ask me whether I wanted to > install it and then made my own decision (eg. buy another card or not). > >If you're really *that* worried you should build everything you use > from >source after trawling through the source. >Personally I'd be much > more concerned about all the other components on >your internet > connection from router to ISP. >Then of course there's your mobile > phone... >If you're using a PC you should probably also be aware > that >there is likely to be bios-installed code which runs in system > >management mode behind the back of the OS, this is also >proprietary > and could also affect the network card and all >other parts of the > machine. Also some of the various management >controllers you might find > hav! > e pretty far-reaching capabilities >in this respect. I agree but all I'm > asking for is maximum awareness. When you know it, then you do what you > think best. I also think we should make it as hard as possible for > government agencies to get our data, that means fight for every detail. > Am I in the wrong forum? This way, at least you know that those that are > able to spy on you are not morons. After all, if you donB4t care about > anything, why donB4t you use Windows 7, Ubuntu or OSX? They are much > easier to configure. >Easiest way to disable the uvideo firmware (and > any bios video spyware) is to stick black electrical tape over the > webcam lens. Thanks for those who pointed me out that uvideo was the > cam. I agree with the black tape approach because I dont use my webcam > often but this is more annoying with the network card... Thanks Stuart > for your insightful comments too.
Re: Re : Re: fw_update
On Thu, May 10, 2012 at 12:03 PM, mark sullivan wrote: > I didn't even have the chance to test if it would work without it. Yes, it should work. Just remove the package with "pkg_delete athn-firmware".
Re : Re: fw_update
>>>If you have concerns with firmwares, swap your card with, for example, an >>>atheros or another card that doesn't need a firmware. >> Some atheros does use firmware, eg athn(4). >Not all the athns. Only USB ones, like the AR9271, need a firmware. Mine is an Atheros (athn, I don't know the model now sorry), not USB and OpenBSD automatically installed athn-firmware-1.1p0. I didn't even have the chance to test if it would work without it. This is the point of my complaint. I would have expected OpenBSD to ask me whether I wanted to install it and then made my own decision (eg. buy another card or not). >If you're really *that* worried you should build everything you use from >source after trawling through the source. >Personally I'd be much more concerned about all the other components on >your internet connection from router to ISP. >Then of course there's your mobile phone... >If you're using a PC you should probably also be aware that >there is likely to be bios-installed code which runs in system >management mode behind the back of the OS, this is also >proprietary and could also affect the network card and all >other parts of the machine. Also some of the various management >controllers you might find hav! e pretty far-reaching capabilities >in this respect. I agree but all I'm asking for is maximum awareness. When you know it, then you do what you think best. I also think we should make it as hard as possible for government agencies to get our data, that means fight for every detail. Am I in the wrong forum? This way, at least you know that those that are able to spy on you are not morons. After all, if you donB4t care about anything, why donB4t you use Windows 7, Ubuntu or OSX? They are much easier to configure. >Easiest way to disable the uvideo firmware (and any bios video spyware) is to stick black electrical tape over the webcam lens. Thanks for those who pointed me out that uvideo was the cam. I agree with the black tape approach because I dont use my webcam often but this is more annoying with the network card... Thanks Stuart for your insightful comments too.
Re: fw_update
On Thu, 10 May 2012 00:46:05 +0200 Alexander Hall wrote: > revision 1.654 > date: 2011/11/08 19:55:52; author: deraadt; state: Exp; lines: +2 -6 > Now that the code is well tested, don't ask the firmware question > anymore. Saves 141 precious bytes on the inside of the media. > ok krw I bet he paused before pressing the enter button on that one, but cd creation pain won over.
Re: fw_update
On Thu, May 10, 2012 at 2:34 AM, Brett wrote: I would like to hear your arguments on this and if there is a simple way to disable fw_update and uninstall in >>>general everything propietary affecting the network card that I have not been warned about. > >>> If you're using a PC you should probably also be aware that >>> there is likely to be bios-installed code which runs in system >>> management mode behind the back of the OS, this is also >>> proprietary and could also affect the network card and all >>> other parts of the machine. Also some of the various management >>> controllers you might find have pretty far-reaching capabilities >>> in this respect. > > >>If you have concerns with firmwares, swap your card with, for example, an >>atheros or another card that doesn't need a firmware. > > Some atheros does use firmware, eg athn(4). Not all the athns. Only USB ones, like the AR9271, need a firmware. cheers, David
Re: fw_update
If you're really *that* worried you should build everything you use from source after trawling through the source. Personally I'd be much more concerned about all the other components on your internet connection from router to ISP. Then of course there's your mobile phone... On May 9, 2012 8:38 PM, "mark sullivan" wrote:
Re: fw_update
Ah, ok. Sorry Mark. I didn't know that. Johan On May 10, 2012 12:46 AM, "Alexander Hall" wrote: > On 05/09/12 22:55, Johan Ryberg wrote: > >> For me as well. Maybe someone needs to read more careful and just don't >> push enter all the way. >> > > While that's a natural thought nowadays, it's not the case here; > > $ cvs log -r1.654 install.sub > /.../ >OPENBSD_5_1: 1.655.0.2 >OPENBSD_5_1_BASE: 1.655 > /.../ > > revision 1.654 > date: 2011/11/08 19:55:52; author: deraadt; state: Exp; lines: +2 -6 > Now that the code is well tested, don't ask the firmware question > anymore. Saves 141 precious bytes on the inside of the media. > ok krw > ==**==** > = > > /Alexander > > // Johan >> On May 9, 2012 10:02 PM, "Tobias Sarnowski" >> wrote: >> >> On 05/09/12 21:33, mark sullivan wrote: >>> >>> Hi everybody, I was coming to OpenBSD 5.1 looking for reasonable privacy and when I install it (amd64 flavour), I see that fw_update automatically installs propietary firmware without my permission. Actually even worse, it updates it automatically from the net! The parts affected are quite meaningful: the network card and the video card... I mean.. Should I request that you install propietary firmware for my sound card too so that everybody can record my voice too? I would like to hear your arguments on this and if there is a simple way to disable fw_update and uninstall in general everything propietary affecting the network card that I have not been warned about. I read on the FAQ that I should have been asked about this firmware but I wasnB4t! (amd64 cd installer). Thanks much, Mark I just want to note: last time I installed OpenBSD (a 5.1-snapshot) this >>> feature worked correctly. I was asked by the installer.
Re: fw_update
On Wed, 2012-05-09 at 23:39 +0200, David Coppa wrote: > What's the purpose of having a non-working wifi card? > > If you have concerns with firmwares, swap your card with, for example, an > atheros or another card that doesn't need a firmware. > > And, btw, the other firmware is for a webcam (uvideo), not the video card... For me the issue was surprise (something I dislike in an installer); I was asked to confirm the download when 5.1 was -current and not asked when it was a release. I had assumed the reason for the confirmation was the license, but the note in the commit suggests it was because fw_update might be buggy. Also, while I recognize this is an edge case, I have in the past sold systems with OpenBSD installed on them to other people, and now that I come to think of it I have no idea whether that's legal to do with, say, iwn-firmware installed on it (it's probably not). Weldon
Re: fw_update
On Wed, 2012-05-09 at 21:33 +0200, mark sullivan wrote: > Hi everybody, > I was coming to OpenBSD 5.1 looking for reasonable privacy and when I > install it (amd64 flavour), I see that fw_update automatically installs > propietary firmware without my permission. Actually even worse, it updates it > automatically from the net! > The parts affected are quite meaningful: the network card and the video > card... I mean.. Should I request that you install propietary firmware > for my sound card too so that everybody can record my voice too? > I would like to hear your arguments on this and if there is a simple way to > disable fw_update and uninstall in general everything propietary affecting > the network card that I have not been warned about. I read on the FAQ that I > should have been asked about this firmware but I wasnB4t! (amd64 cd > installer). > Thanks much, > Mark > This surprised me too, having been used to being asked when 5.1 was still -current. Note that if you don't set up a network interface during the install (or more to the point, don't initially boot with an /etc/hostname.$INTERFACE file), fw_update won't try to run. Weldon
Re: fw_update
On Thu, 10 May 2012 00:55:07 + Ted Unangst wrote: > On Thu, May 10, 2012 at 10:34, Brett wrote: > > > > You can use pf to block those network devices that have firmware you don't > > trust > > Way too late at that point. It's already copied your top zecret data to the > NSA. They have all my data anyway, due to the other camera they secreted in the roof above my desk.
Re: fw_update
On Thu, May 10, 2012 at 10:34, Brett wrote: > You can use pf to block those network devices that have firmware you don't > trust Way too late at that point. It's already copied your top zecret data to the NSA.
Re: fw_update
>>>I would like to hear your arguments on this and if there is a simple way to >>>disable fw_update and uninstall in >>>general everything propietary >>>affecting the network card that I have not been warned about. >> If you're using a PC you should probably also be aware that >> there is likely to be bios-installed code which runs in system >> management mode behind the back of the OS, this is also >> proprietary and could also affect the network card and all >> other parts of the machine. Also some of the various management >> controllers you might find have pretty far-reaching capabilities >> in this respect. >If you have concerns with firmwares, swap your card with, for example, an >atheros or another card that doesn't need a firmware. Some atheros does use firmware, eg athn(4). You can use pf to block those network devices that have firmware you don't trust. Easiest way to disable the uvideo firmware (and any bios video spyware) is to stick black electrical tape over the webcam lens.
Re: fw_update
On 2012-05-09, mark sullivan wrote: > I would like to hear your arguments on this and if there is a > simple way to disable fw_update and uninstall in general everything > propietary affecting the network card that I have not been warned > about. In the cases of the firmware which is installed from a package, usually due to lack of redistribution rights, you can do this: # pkg_delete /var/db/pkg/*-firmware-* # echo 127.0.0.1 firmware.openbsd.org >> /etc/hosts >From your email it seems like this is possibly the main thing you're worried about and is pretty simple to remove/workaround. Other firmware exists in /etc/firmware which is part of the base system (fxp, bnx, myx etc) which never had a question, you could probably do this to remove it and make it hard to reinstall at update time:- # rm -rf /etc/firmware # touch /etc/firmware (tar doesn't like unpacking a dir over a file or vice-versa) There's also firmware / microcode compiled into some drivers like isp(4), see /sys/dev/microcode, you'll have to track down the relevant devices, remove them from kernel config and recompile. Other devices usually have the firmware on some type of rom, eeprom or flash storage device. You're presumably going to need a vendor-supplied tool or a soldering iron to uninstall these. None of the above are really supported though, and in all these cases the simplest way to avoid loading the firmware is to disconnect the relevant device, it will work just as well unplugged as without firmware,. If you're using a PC you should probably also be aware that there is likely to be bios-installed code which runs in system management mode behind the back of the OS, this is also proprietary and could also affect the network card and all other parts of the machine. Also some of the various management controllers you might find have pretty far-reaching capabilities in this respect.
Re: fw_update
On 05/09/12 22:55, Johan Ryberg wrote: For me as well. Maybe someone needs to read more careful and just don't push enter all the way. While that's a natural thought nowadays, it's not the case here; $ cvs log -r1.654 install.sub /.../ OPENBSD_5_1: 1.655.0.2 OPENBSD_5_1_BASE: 1.655 /.../ revision 1.654 date: 2011/11/08 19:55:52; author: deraadt; state: Exp; lines: +2 -6 Now that the code is well tested, don't ask the firmware question anymore. Saves 141 precious bytes on the inside of the media. ok krw = /Alexander // Johan On May 9, 2012 10:02 PM, "Tobias Sarnowski" wrote: On 05/09/12 21:33, mark sullivan wrote: Hi everybody, I was coming to OpenBSD 5.1 looking for reasonable privacy and when I install it (amd64 flavour), I see that fw_update automatically installs propietary firmware without my permission. Actually even worse, it updates it automatically from the net! The parts affected are quite meaningful: the network card and the video card... I mean.. Should I request that you install propietary firmware for my sound card too so that everybody can record my voice too? I would like to hear your arguments on this and if there is a simple way to disable fw_update and uninstall in general everything propietary affecting the network card that I have not been warned about. I read on the FAQ that I should have been asked about this firmware but I wasnB4t! (amd64 cd installer). Thanks much, Mark I just want to note: last time I installed OpenBSD (a 5.1-snapshot) this feature worked correctly. I was asked by the installer.
Re: fw_update
Il giorno 09/mag/2012 21:38, "mark sullivan" ha scritto: > > Hi everybody, > I was coming to OpenBSD 5.1 looking for reasonable privacy and when I install it (amd64 flavour), I see that fw_update automatically installs propietary firmware without my permission. Actually even worse, it updates it automatically from the net! > The parts affected are quite meaningful: the network card and the video card... I mean.. Should I request that you install propietary firmware for my sound card too so that everybody can record my voice too? What's the purpose of having a non-working wifi card? If you have concerns with firmwares, swap your card with, for example, an atheros or another card that doesn't need a firmware. And, btw, the other firmware is for a webcam (uvideo), not the video card... Ciao David
Re: fw_update
On Wed, May 09, 2012 at 21:33, mark sullivan wrote: > I was coming to OpenBSD 5.1 looking for reasonable privacy and when I > install it (amd64 flavour), I see that fw_update automatically installs > propietary firmware without my permission. Actually even worse, it updates > it automatically from the net! > The parts affected are quite meaningful: the network card and the video > card... I mean.. Should I request that you install propietary > firmware for my sound card too so that everybody can record my voice too? > I would like to hear your arguments on this and if there is a simple way > to disable fw_update and uninstall in general everything propietary > affecting the network card that I have not been warned about. I read on > the FAQ that I should have been asked about this firmware but I wasnB4t! > (amd64 cd installer). The firmware is only loaded onto the network card if you enable the interface using ifconfig. If you do not trust your network card, don't use it. If you don't trust the network card, but you still want to use it, you're shit out of luck. It won't work without the firmware.
Re: fw_update
For me as well. Maybe someone needs to read more careful and just don't push enter all the way. // Johan On May 9, 2012 10:02 PM, "Tobias Sarnowski" wrote: > On 05/09/12 21:33, mark sullivan wrote: > >> Hi everybody, >> I was coming to OpenBSD 5.1 looking for reasonable privacy and when I >> install it (amd64 flavour), I see that fw_update automatically installs >> propietary firmware without my permission. Actually even worse, it updates >> it automatically from the net! >> The parts affected are quite meaningful: the network card and the video >> card... I mean.. Should I request that you install propietary firmware >> for my sound card too so that everybody can record my voice too? >> I would like to hear your arguments on this and if there is a simple way >> to disable fw_update and uninstall in general everything propietary >> affecting the network card that I have not been warned about. I read on the >> FAQ that I should have been asked about this firmware but I wasnB4t! (amd64 >> cd installer). >> Thanks much, >> Mark >> >> I just want to note: last time I installed OpenBSD (a 5.1-snapshot) this > feature worked correctly. I was asked by the installer.
Re: fw_update
On 05/09/12 21:33, mark sullivan wrote: Hi everybody, I was coming to OpenBSD 5.1 looking for reasonable privacy and when I install it (amd64 flavour), I see that fw_update automatically installs propietary firmware without my permission. Actually even worse, it updates it automatically from the net! The parts affected are quite meaningful: the network card and the video card... I mean.. Should I request that you install propietary firmware for my sound card too so that everybody can record my voice too? I would like to hear your arguments on this and if there is a simple way to disable fw_update and uninstall in general everything propietary affecting the network card that I have not been warned about. I read on the FAQ that I should have been asked about this firmware but I wasnB4t! (amd64 cd installer). Thanks much, Mark I just want to note: last time I installed OpenBSD (a 5.1-snapshot) this feature worked correctly. I was asked by the installer.
