Re: Use of fw_update to bootstrap OBSD
On Mon, Oct 09, 2023 at 08:01:14PM -0700, Andrew Hewus Fresh wrote:
> On Sun, Oct 08, 2023 at 02:36:16PM +0200, Thomas wrote:
> > Hello,
> >
> > I am installing OpenBSD on an old xps13 9380. The WiFi is not
> > supported and so I am using a usb dongle for which I need the
> > athn-firmware. I get it to work and now wanting to prep a USB disk
> > with all necessary firmware. I'm following the FAQ#4 on the website
> > (I suppose it works with more firmware than just the WiFi).
>
> fw_update does download and verify the signature on the SHA256.sig,
> however it does then overwrite the one with the signature with one
> without the signature.
I think this is as simple has having signify write the output to
/dev/null. It seems to work in my testing.
Index: fw_update.sh
=======
RCS file: /cvs/src/usr.sbin/fw_update/fw_update.sh,v
retrieving revision 1.50
diff -u -p -r1.50 fw_update.sh
--- fw_update.sh28 Sep 2023 01:18:52 - 1.50
+++ fw_update.sh11 Oct 2023 02:37:24 -
@@ -180,7 +180,7 @@ fetch_cfile() {
set +o noclobber # we want to get the latest CFILE
fetch "$CFILE" || return 1
set -o noclobber
- ! signify -qVep "$FWPUB_KEY" -x "$CFILE" -m "$CFILE" &&
+ ! signify -qVep "$FWPUB_KEY" -x "$CFILE" -m /dev/null &&
warn "Signature check of SHA256.sig failed" &&
rm -f "$CFILE" && return 1
elif [ ! -e "$CFILE" ]; then
Re: Use of fw_update to bootstrap OBSD
On Sun, Oct 08, 2023 at 02:36:16PM +0200, Thomas wrote: > Hello, > > I am installing OpenBSD on an old xps13 9380. The WiFi is not supported and > so I am using a usb dongle for which I need the athn-firmware. I get it to > work and now wanting to prep a USB disk with all necessary firmware. I'm > following the FAQ#4 on the website (I suppose it works with more firmware > than just the WiFi). > > So, now to my question. Using fw_update -F to the current dir does download > all firmware (5 files) and SHA256.sig. However, the file SHA256.sig does not > include the signature, using signify like so: > > signify -Cp /etc/signify/openbsd-73-fw.pub -x SHA256.sig * > > Fails with message: invalid comment in SHA256.sig; must start with 'untrusted > comment: ' > > Downloading the SHA256.sig from firmware.openbsd.org/firmware/7.3/SHA256.sig > which includes the signature does work. > > Is it that normal behaviour? Since the firmware.openbsd.org site is not > HTTPS, and that, at least for me, fw_update does not download signed > SHA256.sig, would it not be possible to download unintended files? fw_update does download and verify the signature on the SHA256.sig, however it does then overwrite the one with the signature with one without the signature. Normally once it's verified we trust the location of the files and so we don't need to verify the signature again, but in the download case that may not be true (even if we trust the user when installing from a local directory and don't require a signed SHA256 file). https://github.com/openbsd/src/blob/master/usr.sbin/fw_update/fw_update.sh#L183-L185 > Thanks in advance, Thanks for noticing. I'll look at how best to adjust that when I have time to look at fw_update again.
Use of fw_update to bootstrap OBSD
Hello, I am installing OpenBSD on an old xps13 9380. The WiFi is not supported and so I am using a usb dongle for which I need the athn-firmware. I get it to work and now wanting to prep a USB disk with all necessary firmware. I'm following the FAQ#4 on the website (I suppose it works with more firmware than just the WiFi). So, now to my question. Using fw_update -F to the current dir does download all firmware (5 files) and SHA256.sig. However, the file SHA256.sig does not include the signature, using signify like so: signify -Cp /etc/signify/openbsd-73-fw.pub -x SHA256.sig * Fails with message: invalid comment in SHA256.sig; must start with 'untrusted comment: ' Downloading the SHA256.sig from firmware.openbsd.org/firmware/7.3/SHA256.sig which includes the signature does work. Is it that normal behaviour? Since the firmware.openbsd.org site is not HTTPS, and that, at least for me, fw_update does not download signed SHA256.sig, would it not be possible to download unintended files? Thanks in advance, Thomas
Re: Upgrade: Unbound constraint let fw_update always fail
Endeover: In 7.3, I end up starting also unbound service by rcctl instead of unbound-control (losing maybe something about security) hoping to give me a better general standard to control my services, including my approach to sysupgrade. Thanks to everyone who reply in the thread. -- Daniele Bonini
Re: Upgrade: Unbound constraint let fw_update always fail
Thanks Steve. Jul 30, 2023 00:07:35 Steve Litt : > I use runit (on Void Linux) every day, and love it to death. Runit is > extremely simple. S6 is a little more capable and a little more complex. Thank you for all the hints, expecially about runit, I didn't know it. I'm going trying to fix things related to my script and my approach to sysupgrade. if conditions will change and push me to that I will certainly do not miss to try your solution that appears a little more sophisticated. -- Daniele Bonini
Re: Upgrade: Unbound constraint let fw_update always fail
Daniele B. said on Tue, 25 Jul 2023 16:33:50 +0200 (GMT+02:00) >My unattended upgrade happend like that: > >- I took up unbound >- sysupgrade >- 1st fw_update (this probbly is okay) >- reboot >- installation of the sets >- 2nd fw_update (this fails because unattended, local Unbound is down) >- reboot >- 3rd fw_update (this fails because unattended, local Unbound is down) >- syspatch (this fails as well) > >I finally took up my dev environment and run fw_update & syspatch. > >If the first fw_update is enough to be sure about a sucessfull >installation then case solved, just keeping the good stuff from the >thread.. Hi Daniele, OK, I'm hearing that you want ongoing control of which daemons are up and which are down, and that precludes just putting them in your /etc/rc.conf and/or /etc/rc.conf.local. There are two alternative process supervisors, runit and s6, that can give you much finer control over your daemons. Both have been designed from the ground up to be portable between Linux and every BSD distribution. You can use either runit or s6 to augment your rc.conf. You needn't *replace* rc.conf or rc.conf.local, you can *augment* them. I use runit (on Void Linux) every day, and love it to death. Runit is extremely simple. S6 is a little more capable and a little more complex. You can get lots of extremely authoritative information about runit and s6 on the Supervision mailing list. To subscribe, send an empty message to supervision-subscr...@list.skarnet.org. HTH, SteveT Steve Litt Autumn 2022 featured book: Thriving in Tough Times http://www.troubleshooters.com/bookstore/thrive.htm
Re: Upgrade: Unbound constraint let fw_update always fail
On Jul 28, 2023 20:00:24 I was still sleeping when suddenly Paul said: > If you really want to go without DNS resolution, I invite you to > travel back a few decades and learn about /etc/hosts. did you hear my "True, the hosts.. Oh Jesus!"... ? Many thx! :D -- Daniele Bonini
Re: Upgrade: Unbound constraint let fw_update always fail
I don't understand - if you configure your system to not have working DNS resolution, then you will not have working DNS resolution. fw_update needs working DNS resolution, so yeah .. if you break the latter, you break the former. Don't break DNS resolution. You really get what you pay for. Having said all that... If you really want to go without DNS resolution, I invite you to travel back a few decades and learn about /etc/hosts. Maybe you can FTP a hosts file from somewhere, for that true historic experience .. but alternatively you can also echo 2a02:898:28:500::3 firmware.openbsd.org | doas tee -a /etc/hosts Good luck with that. Paul 'WEiRD' de Weerd NB: full disclosure, the IP address I gave is the firmware mirror hosted by me; I didn't want to point people to someone else's .. but I also kinda hope noone (else) is foolish enough to break their DNS resolution in such a way to need this kind of tomfoolery. On Tue, Jul 25, 2023 at 09:58:35AM +0200, Daniele B. wrote: | | Hello, | | Just coming from my fresh upgrade to OpenBSD 7.3 and thanks again for | it.. ;) | | No particular problem except my realization that with my settings | (unbound started manually) fw_update goes to fail (all the three | attempts) on each (unattended) upgrade. If fw_update happens to be a | constraint for a successful upgrade, and luckily was not the case this | time, bad times for sure.. | | Any suggestion about it? Thanks! | | | | -- | Daniele Bonini | | -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: Upgrade: Unbound constraint let fw_update always fail
My unattended upgrade happend like that: - I took up unbound - sysupgrade - 1st fw_update (this probbly is okay) - reboot - installation of the sets - 2nd fw_update (this fails because unattended, local Unbound is down) - reboot - 3rd fw_update (this fails because unattended, local Unbound is down) - syspatch (this fails as well) I finally took up my dev environment and run fw_update & syspatch. If the first fw_update is enough to be sure about a sucessfull installation then case solved, just keeping the good stuff from the thread.. -- Daniele Bonini Jul 25, 2023 15:28:57 Daniele B. : > Thanks Steve, > > Jul 25, 2023 14:41:53 Steve Litt : > >> chattr -i resolv.conf && echo nameserver 8.8.8.8 >> resolv.conf && chattr +i >> resolv.conf >> >> I also don't understand why you start unbound manually instead of from >> computer initialization. It sounds like if unbound started before >> fw_update, there would be no problem > > I also would like the possibility to rewind my mindset to two years ago to > have the proper > technical answer when I need it.. However I try to answer you.. > > Basically I think while experimenting I found interesting the possibility to > have full > control over my dev environment and decide when to take up/down all my needs, > including the network.. > Indeed I was so happy about my findings that I decided to give to it also a > graphical interface > to make it more amousing. :D > > If you want to help, in my script to switch the dev environment down I miss > the possibility to take down Unbound > that one time launched is very hard to switch off, still my script doesn't do > that.. > > I think the suggestion to implement an ad-hoc network settings for the > unattended installation could > be interesting also to cover that few cases of disparate accesses to > Internet, indeed. But here you should > have a some more case studies than me. > > -- Daniele Bonini > > Jul 25, 2023 14:41:53 Steve Litt : > >> chattr -i resolv.conf && echo nameserver 8.8.8.8 >> resolv.conf && chattr +i >> resolv.conf >> >> I also don't understand why you start unbound manually instead of from >> computer initialization. It sounds like if unbound started before >> fw_update, there would be no problem.
Re: Upgrade: Unbound constraint let fw_update always fail
Thanks Steve, Jul 25, 2023 14:41:53 Steve Litt : > chattr -i resolv.conf && echo nameserver 8.8.8.8 >> resolv.conf && chattr +i > resolv.conf > > I also don't understand why you start unbound manually instead of from > computer initialization. It sounds like if unbound started before > fw_update, there would be no problem I also would like the possibility to rewind my mindset to two years ago to have the proper technical answer when I need it.. However I try to answer you.. Basically I think while experimenting I found interesting the possibility to have full control over my dev environment and decide when to take up/down all my needs, including the network.. Indeed I was so happy about my findings that I decided to give to it also a graphical interface to make it more amousing. :D If you want to help, in my script to switch the dev environment down I miss the possibility to take down Unbound that one time launched is very hard to switch off, still my script doesn't do that.. I think the suggestion to implement an ad-hoc network settings for the unattended installation could be interesting also to cover that few cases of disparate accesses to Internet, indeed. But here you should have a some more case studies than me. -- Daniele Bonini Jul 25, 2023 14:41:53 Steve Litt : > chattr -i resolv.conf && echo nameserver 8.8.8.8 >> resolv.conf && chattr +i > resolv.conf > > I also don't understand why you start unbound manually instead of from > computer initialization. It sounds like if unbound started before > fw_update, there would be no problem.
Re: Upgrade: Unbound constraint let fw_update always fail
Daniele B. said on Tue, 25 Jul 2023 11:29:09 +0200 (GMT+02:00) >Hello Stuart, thanks for this one.. > >Yes, I agree that the final solution could be only the replace my >listed nameserver. But do you remember I was using also the unmutable >flag on resolv.conf ? :D chattr -i resolv.conf && echo nameserver 8.8.8.8 >> resolv.conf && chattr +i resolv.conf I also don't understand why you start unbound manually instead of from computer initialization. It sounds like if unbound started before fw_update, there would be no problem. SteveT Steve Litt Autumn 2022 featured book: Thriving in Tough Times http://www.troubleshooters.com/bookstore/thrive.htm
Re: Upgrade: Unbound constraint let fw_update always fail
Hello Stuart, thanks for this one.. Yes, I agree that the final solution could be only the replace my listed nameserver. But do you remember I was using also the unmutable flag on resolv.conf ? :D I do not want to awake the lions and indeed I'm much happy about my *unbound system* but having a free to use failover network setting for the specific case of the unattended installation sounds enough attractive, isn it? Jul 25, 2023 11:00:27 Stuart Henderson : > On 2023-07-25, Daniele B. wrote: >> >> Hello, >> >> Just coming from my fresh upgrade to OpenBSD 7.3 and thanks again for >> it.. ;) >> >> No particular problem except my realization that with my settings >> (unbound started manually) fw_update goes to fail (all the three >> attempts) on each (unattended) upgrade. If fw_update happens to be a >> constraint for a successful upgrade, and luckily was not the case this >> time, bad times for sure.. >> >> Any suggestion about it? Thanks! > > List a nameserver other than just your local machine in resolv.conf.
Re: Upgrade: Unbound constraint let fw_update always fail
On 2023-07-25, Daniele B. wrote: > > Hello, > > Just coming from my fresh upgrade to OpenBSD 7.3 and thanks again for > it.. ;) > > No particular problem except my realization that with my settings > (unbound started manually) fw_update goes to fail (all the three > attempts) on each (unattended) upgrade. If fw_update happens to be a > constraint for a successful upgrade, and luckily was not the case this > time, bad times for sure.. > > Any suggestion about it? Thanks! List a nameserver other than just your local machine in resolv.conf.
Upgrade: Unbound constraint let fw_update always fail
Hello, Just coming from my fresh upgrade to OpenBSD 7.3 and thanks again for it.. ;) No particular problem except my realization that with my settings (unbound started manually) fw_update goes to fail (all the three attempts) on each (unattended) upgrade. If fw_update happens to be a constraint for a successful upgrade, and luckily was not the case this time, bad times for sure.. Any suggestion about it? Thanks! -- Daniele Bonini
Re: Possible typo in fw_update
Andrew Hewus Fresh writes:
> On Sun, Dec 11, 2022 at 08:06:24PM -0500, Rob Whitlock wrote:
> > On line 408, fw_update has the expression ${LOCALSRC:#file:}. The parameter
> > substitution ${name:#word} is not documented in the manual page for ksh yet
> > its behavior seems to be equivalent to ${LOCALSRC#file:}. Assuming this is
> > a typo, a patch is provided to remove the colon. If it is not a typo, could
> > someone explain what this syntax does?
>
> It was a typo, committed, thanks!
>
>
> > Is this was a typo however, and this parameter substitution is not
> > officially supported, why did ksh not complain?
>
> Not having read it, I assume the implementation reads the : and sets a
> flag that says "must be be NULL" for the -, +, =, and ? substitutions
> and the validation that the next character is one of those four is
> missing.
It does this:
/* allow :# and :% (ksh88 compat) */
if (c == ':') {
*wp++ = CHAR, *wp++ = c;
c = getsc();
}
... introduced in lex.c 1.11 in 1998. I think it's safe.
> An email to bugs@ with this question might get the attention of folks
> who are more familiar with ksh internals and whether fixing this being
> too accepting is worth the code and the likelihood of breaking scripts
> with typos like this one.
>From prior excavation deep in the bowels of yylex:
${-expansion expects a variable name and modifiers. The
name is scanned for by get_brace_var below and then
modification by ``#'' or ``%'' is detected. ``:#'' and
``:%'' are also accepted for compatibility with ksh88.
This seems like a good opportunity for shameless self-promotion of
the full excavation at http://zeus.jtan.com/~chohag/ksh/ (section
347 "Detect ${-expansion", page 147).
Matthew
Re: Possible typo in fw_update
On Sun, Dec 11, 2022 at 08:06:24PM -0500, Rob Whitlock wrote:
> On line 408, fw_update has the expression ${LOCALSRC:#file:}. The parameter
> substitution ${name:#word} is not documented in the manual page for ksh yet
> its behavior seems to be equivalent to ${LOCALSRC#file:}. Assuming this is
> a typo, a patch is provided to remove the colon. If it is not a typo, could
> someone explain what this syntax does?
>
> Is this was a typo however, and this parameter substitution is not
> officially supported, why did ksh not complain?
I would guess syntax ${name:#word} is akin to other colon substitutions
${name:-word}, ${name:=word}, ${name:+word}, ${name:?word} although
it is not documented.
${name:%word} works too (and is not documented either)
And actually man page says that colon can be omitted from :- := :+ :?
which hints that # and % are treated as substitutions with omitted colon.
I wonder if we would rather update man page of ksh.
-Kastus
Re: Possible typo in fw_update
On Sun, Dec 11, 2022 at 08:06:24PM -0500, Rob Whitlock wrote:
> On line 408, fw_update has the expression ${LOCALSRC:#file:}. The parameter
> substitution ${name:#word} is not documented in the manual page for ksh yet
> its behavior seems to be equivalent to ${LOCALSRC#file:}. Assuming this is
> a typo, a patch is provided to remove the colon. If it is not a typo, could
> someone explain what this syntax does?
It was a typo, committed, thanks!
> Is this was a typo however, and this parameter substitution is not
> officially supported, why did ksh not complain?
Not having read it, I assume the implementation reads the : and sets a
flag that says "must be be NULL" for the -, +, =, and ? substitutions
and the validation that the next character is one of those four is
missing.
An email to bugs@ with this question might get the attention of folks
who are more familiar with ksh internals and whether fixing this being
too accepting is worth the code and the likelihood of breaking scripts
with typos like this one.
> Rob
>
> diff --git usr.sbin/fw_update/fw_update.sh usr.sbin/fw_update/fw_update.sh
> index 4b77d4c7bd7..dbc80257228 100644
> --- usr.sbin/fw_update/fw_update.sh
> +++ usr.sbin/fw_update/fw_update.sh
> @@ -405,7 +405,7 @@ if [ "$LOCALSRC" ]; then
> FWURL="${LOCALSRC}"
> LOCALSRC=
> else
> - LOCALSRC="${LOCALSRC:#file:}"
> + LOCALSRC="${LOCALSRC#file:}"
> ! [ -d "$LOCALSRC" ] &&
> echo "The path must be a URL or an existing directory"
> >&2 &&
> exit 1
Possible typo in fw_update
On line 408, fw_update has the expression ${LOCALSRC:#file:}. The parameter
substitution ${name:#word} is not documented in the manual page for ksh yet
its behavior seems to be equivalent to ${LOCALSRC#file:}. Assuming this is
a typo, a patch is provided to remove the colon. If it is not a typo, could
someone explain what this syntax does?
Is this was a typo however, and this parameter substitution is not
officially supported, why did ksh not complain?
Rob
diff --git usr.sbin/fw_update/fw_update.sh usr.sbin/fw_update/fw_update.sh
index 4b77d4c7bd7..dbc80257228 100644
--- usr.sbin/fw_update/fw_update.sh
+++ usr.sbin/fw_update/fw_update.sh
@@ -405,7 +405,7 @@ if [ "$LOCALSRC" ]; then
FWURL="${LOCALSRC}"
LOCALSRC=
else
- LOCALSRC="${LOCALSRC:#file:}"
+ LOCALSRC="${LOCALSRC#file:}"
! [ -d "$LOCALSRC" ] &&
echo "The path must be a URL or an existing directory"
>&2 &&
exit 1
Re: Is fw_update documentation outdated?
Hi Ingo, On 2021/12/26 23:26, Ingo Schwarze wrote: > Hi Alexander, > > Alexander wrote on Sun, Dec 26, 2021 at 08:11:51PM +: > > On 2021/12/25 18:02, Ingo Schwarze wrote: > > >> The new fw_update shell script is not in CVS yet. > >> > >> This command provides a clue that could lead you to suspect the above: > >> > >>$ grep -m 1 OpenBSD $(which fw_update) > >> #$OpenBSD$ > >> > >> That's a CVS tag which has not been processed by CVS yet. > > > Just to keep the noise on the mailing list down in case I run into > > something like this again at some point: > > Is that tag the usual indicator of such uncommitted code > > No, it is not usual. In most cases of uncommitted patches that > are being tested in snapshots, the patches change *.c files before > compiling. Compiled files in OpenBSD usually do not contain the CVS > IDs of the source files used. Some historical operating systems > (and maybe even a few current systems, i'm not sure about that) > did include SCCS or CVS tags into compiled files, and that's what > the what(1) utility was designed for in the remote past: > >$ what /usr/src/bin/cat/*.c > /usr/src/bin/cat/cat.c: > $OpenBSD: cat.c,v 1.32 2021/10/24 21:24:21 deraadt Exp $ >$ what /bin/cat > /bin/cat: >$ > > On some other or older systems, "what /bin/cat" might also return the > CVS ID(s). But even that wouldn't really help for your purpose. > In most cases, it would only be the ID of the latest commited > revision; the patch being tested would typically change some lines > of code, but it would usually not change the ID. > > You only saw the unexpanded $OpenBSD$ ID in this case because it > was a completely new uncommitted file intended for later commit, > and because it was not a compiled file but a script where the > source code gets installed directly. > > In the rare cases where you do find such an unexpanded CVS ID, it's a > medium strength indicator pointing to a possible uncommitted patch, > but even then it's not 100% certain - there could be other, even more > unusual reasons for seeing such a thing. > > > or are there other things I should look for before asking here again? > > In general, it can be quite hard to identify uncommitted changes, > even for developers. A generally working way to identify them > basically does not exist. (And maintaining an official list would > be a horrendous make-work project.) > > Sometimes, compiling the tool that behaves strangely yourself > from CVS -current sources and comparing behaviour to the same > tool in the snapshot may help - if behaviour differs, that's > a medium strength indicator of a possible uncommitted patch. > Or, of course, you might have miscompiled it... > Your specific example demonstrates that this suggestion does > not always help: nothing to compile there, and you (rightly) > failed to even find any sources... > > For users, i think best practice is as follows: if something does not > work as you think it should, and if reviewing the manual pages, the > FAQ, and searching through recent postings on tech@, bugs@, and misc@ > still leaves you wondering, then ask, providing as much much detail > as you can: which exact OS version or snapshot, what exactly you did, > what you expected, and what happened instead. If the tool misbehaves > in the snapshot but works when you compile it yourself from -current, > say so. In other words, your report was of very reasonable quality. > Nobody will expect that you make a definitive statement like "this is a > regression caused by an uncommitted patch in snapshots" in your report. Thanks a lot. That's a very helpful explanation and I will keep that in mind. > > If it appears to misbehave, it's worth a report. And if there > is an uncommitted patch in snapshot, than hopefully at least one > developer is watching closely. After all, asking Theo to put a > patch into snapshots for testing but then *not* watch the bugs@ > mailing list for reports that might be related would make very > little sense! > > Yours, > Ingo > > P.S. > Currently, it looks relatively unlikely that the new fw_update(8) > is really going to loose the -n option; or else it might regrow > it shortly after the initial commit. No guarantee though. > Best advice for users is to wait for the dust in this area to settle. I will do that ;) Thank you for making an os that is actually so reliable and well-designed that I'm not worried at all right now. Best regards, Alexander
Re: Is fw_update documentation outdated?
Hi Alexander, Alexander wrote on Sun, Dec 26, 2021 at 08:11:51PM +: > On 2021/12/25 18:02, Ingo Schwarze wrote: >> The new fw_update shell script is not in CVS yet. >> >> This command provides a clue that could lead you to suspect the above: >> >>$ grep -m 1 OpenBSD $(which fw_update) >> # $OpenBSD$ >> >> That's a CVS tag which has not been processed by CVS yet. > Just to keep the noise on the mailing list down in case I run into > something like this again at some point: > Is that tag the usual indicator of such uncommitted code No, it is not usual. In most cases of uncommitted patches that are being tested in snapshots, the patches change *.c files before compiling. Compiled files in OpenBSD usually do not contain the CVS IDs of the source files used. Some historical operating systems (and maybe even a few current systems, i'm not sure about that) did include SCCS or CVS tags into compiled files, and that's what the what(1) utility was designed for in the remote past: $ what /usr/src/bin/cat/*.c /usr/src/bin/cat/cat.c: $OpenBSD: cat.c,v 1.32 2021/10/24 21:24:21 deraadt Exp $ $ what /bin/cat /bin/cat: $ On some other or older systems, "what /bin/cat" might also return the CVS ID(s). But even that wouldn't really help for your purpose. In most cases, it would only be the ID of the latest commited revision; the patch being tested would typically change some lines of code, but it would usually not change the ID. You only saw the unexpanded $OpenBSD$ ID in this case because it was a completely new uncommitted file intended for later commit, and because it was not a compiled file but a script where the source code gets installed directly. In the rare cases where you do find such an unexpanded CVS ID, it's a medium strength indicator pointing to a possible uncommitted patch, but even then it's not 100% certain - there could be other, even more unusual reasons for seeing such a thing. > or are there other things I should look for before asking here again? In general, it can be quite hard to identify uncommitted changes, even for developers. A generally working way to identify them basically does not exist. (And maintaining an official list would be a horrendous make-work project.) Sometimes, compiling the tool that behaves strangely yourself from CVS -current sources and comparing behaviour to the same tool in the snapshot may help - if behaviour differs, that's a medium strength indicator of a possible uncommitted patch. Or, of course, you might have miscompiled it... Your specific example demonstrates that this suggestion does not always help: nothing to compile there, and you (rightly) failed to even find any sources... For users, i think best practice is as follows: if something does not work as you think it should, and if reviewing the manual pages, the FAQ, and searching through recent postings on tech@, bugs@, and misc@ still leaves you wondering, then ask, providing as much much detail as you can: which exact OS version or snapshot, what exactly you did, what you expected, and what happened instead. If the tool misbehaves in the snapshot but works when you compile it yourself from -current, say so. In other words, your report was of very reasonable quality. Nobody will expect that you make a definitive statement like "this is a regression caused by an uncommitted patch in snapshots" in your report. If it appears to misbehave, it's worth a report. And if there is an uncommitted patch in snapshot, than hopefully at least one developer is watching closely. After all, asking Theo to put a patch into snapshots for testing but then *not* watch the bugs@ mailing list for reports that might be related would make very little sense! Yours, Ingo P.S. Currently, it looks relatively unlikely that the new fw_update(8) is really going to loose the -n option; or else it might regrow it shortly after the initial commit. No guarantee though. Best advice for users is to wait for the dust in this area to settle.
Re: Is fw_update documentation outdated?
Thank you everyone for the helpful and detailed explanations! On 2021/12/25 18:02, Ingo Schwarze wrote: > The new fw_update shell script is not in CVS yet. > > This command provides a clue that could lead you to suspect the above: > >$ grep -m 1 OpenBSD $(which fw_update) > # $OpenBSD$ > > That's a CVS tag which has not been processed by CVS yet. > Just to keep the noise on the mailing list down in case I run into something like this again at some point: Is that tag the usual indicator of such uncommitted code or are there other things I should look for before asking here again? Thanks again. Best regards, Alexander
Re: Is fw_update documentation outdated?
Hi Alexander, Alexander wrote on Sat, Dec 25, 2021 at 04:07:07PM +: > I just wanted to check for new firmware versions: > > $ fw_update -n > fw_update: unknown option -- -n > usage: fw_update [-d | -D] [-av] [-p path] [driver | file ...] > > This used to work /usr/sbin/fw_update used to be a symbolic link to /usr/sbin/pkg_add, but recent snapshots appear to contain an uncommitted change by Andrew Fresh that makes /usr/sbin/fw_update a stand- alone shell script such that it will become usable in the installer. For now, you can still run the pkg_add-based version that supports the -n option like this: $ cd $ cp /usr/sbin/pkg_add fw_update $ perl ./fw_update -n But this may or may not become impossible in the near future. Snapshot do sometimes contain patches that are being evaluated before committing them. > and is still documented like this in > > $ man 8 fw_update > [...] > -n Dry run. Do not actually install or update any firmware > and whether it appears to be required by a driver. > [...] > (also https://man.openbsd.org/fw_update) I expect the documentation will be updated when this gets committed, or shortly afterwards. > But /usr/sbin/fw_update does not contain this option anymore and > consequently produces the error above. > This mismatch puzzles me a bit and I'm even more confused when looking > at https://cvsweb.openbsd.org/src/usr.sbin/fw_update/ which has been in > the attic for the last 6 years. > > I'm guessing I'm just uninformed and don't understand CVSweb but I'd > like to learn, so: > Is the documentation for fw_update outdated? > Where do I actually find the version history of the fw_update that is > installed on my system in CVSweb? That history is purely a matter of the future. The new fw_update shell script is not in CVS yet. This command provides a clue that could lead you to suspect the above: $ grep -m 1 OpenBSD $(which fw_update) # $OpenBSD$ That's a CVS tag which has not been processed by CVS yet. Yours, Ingo > My system: > $ head -1 /etc/motd > OpenBSD 7.0-current (GENERIC.MP) #200: Fri Dec 24 22:15:01 MST 2021
Re: Is fw_update documentation outdated?
fw_update is being replaced with a new program, and this is being tested in snapshots to ensure we have coverage all all circumstances. The new program is capable of updating firmwares while in the bsd.rd install/upgrade phase. This means some firmwares (specially *drm firmwares) will get updated then, rather than after the reboot. This means noone needs a 2nd reboot to activate those firmwares. Some behaviours of the existing program may not survive, and others may get changes. It isn't finished yet, when it is, then documentation will be updated. Alexander wrote: > Hi all, > > I just wanted to check for new firmware versions: > > $ fw_update -n > fw_update: unknown option -- -n > usage: fw_update [-d | -D] [-av] [-p path] [driver | file ...] > > This used to work and is still documented like this in > > $ man 8 fw_update > [...] > -n Dry run. Do not actually install or update any firmware > and whether it appears to be required by a driver. > [...] > (also https://man.openbsd.org/fw_update) > > But /usr/sbin/fw_update does not contain this option anymore and > consequently produces the error above. > This mismatch puzzles me a bit and I'm even more confused when looking > at https://cvsweb.openbsd.org/src/usr.sbin/fw_update/ which has been in > the attic for the last 6 years. > > I'm guessing I'm just uninformed and don't understand CVSweb but I'd > like to learn, so: > Is the documentation for fw_update outdated? > Where do I actually find the version history of the fw_update that is > installed on my system in CVSweb? > > My system: > $ head -1 /etc/motd > OpenBSD 7.0-current (GENERIC.MP) #200: Fri Dec 24 22:15:01 MST 2021 > > Thanks in advance. > > Best regards, > Alexander >
Re: Is fw_update documentation outdated?
On Sat, Dec 25, 2021 at 04:07:07PM +, Alexander wrote: > at https://cvsweb.openbsd.org/src/usr.sbin/fw_update/ which has been in > the attic for the last 6 years. > Where do I actually find the version history of the fw_update that is > installed on my system in CVSweb? fw_update is a hard link to pkg_add. Try looking in: /usr/src/usr.sbin/pkg_add
Is fw_update documentation outdated?
Hi all, I just wanted to check for new firmware versions: $ fw_update -n fw_update: unknown option -- -n usage: fw_update [-d | -D] [-av] [-p path] [driver | file ...] This used to work and is still documented like this in $ man 8 fw_update [...] -n Dry run. Do not actually install or update any firmware and whether it appears to be required by a driver. [...] (also https://man.openbsd.org/fw_update) But /usr/sbin/fw_update does not contain this option anymore and consequently produces the error above. This mismatch puzzles me a bit and I'm even more confused when looking at https://cvsweb.openbsd.org/src/usr.sbin/fw_update/ which has been in the attic for the last 6 years. I'm guessing I'm just uninformed and don't understand CVSweb but I'd like to learn, so: Is the documentation for fw_update outdated? Where do I actually find the version history of the fw_update that is installed on my system in CVSweb? My system: $ head -1 /etc/motd OpenBSD 7.0-current (GENERIC.MP) #200: Fri Dec 24 22:15:01 MST 2021 Thanks in advance. Best regards, Alexander
snapshot install stuck at fw_update
Old snapshot working fine at first run, installing all fw_update needed packages: Build date: 1635104269 - Sun Oct 24 19:37:49 UTC 2021 Last snapshot, stuck at fw_update, not installing. Using manual fw_update works fine after that. Build date: 1635178887 - Mon Oct 25 16:21:27 UTC 2021 After multiple nervous and i got this: Ustar [ http://firmware.openbsd.org/firmware/snapshots/radeondrm-firmware-202012128.tgz][firmware/radeon/BONAIRE_uvd.bin]: Premature end of archive [ ...] Kernel boot was resumed fine. Not hitting any key let it stuck for some time, no boot.
Re: Can I shorten fw_update download timeout?
On 2021-04-08, Luke Small wrote: > I make unbound connect to dnscrypt-proxy and after an update, it’ll just > sit there for what seems like 2 minutes while fw_update inevitably fails > before turning on dnscrypt-proxy. I’ve been running snapshots and that’s > really dumb. Or is there a way to have unbound connect to a failover server > when the default resolver isn’t responsive that I’m not aware of?-- > -Luke > You can have >=0 forward-addr lines. >From unbound.conf(5): "There may be multiple forward-zone: clauses. Each with a name: and zero or more hostnames or IP addresses."
Re: Can I shorten fw_update download timeout?
On Thu, Apr 08, 2021 at 01:50:59PM -0500, Luke Small wrote: > I make unbound connect to dnscrypt-proxy and after an update, it’ll just > sit there for what seems like 2 minutes while fw_update inevitably fails > before turning on dnscrypt-proxy. I’ve been running snapshots and that’s > really dumb. Or is there a way to have unbound connect to a failover server > when the default resolver isn’t responsive that I’m not aware of?-- > -Luke well there are many ways to go about this. Both sysupgrade and fw_update are scripts so they can be easily modified to your needs. Copy them to your path that takes precedence and customise them to your needs. fw_update actually is a perl script that calls the pkg_xxx with the fw_update mode. >From the pkg_add manpage you can see that you can specify FETCH_CMD to whatever you want. Now you can either write a small script yourself to either send a SIGALRM after X seconds and listen for that, or use a another command like curl which implements connect timeouts. like so FETCH_CMD="/usr/local/bin/curl --connect-timeout 1" fw_update signature.asc Description: PGP signature
Can I shorten fw_update download timeout?
I make unbound connect to dnscrypt-proxy and after an update, it’ll just sit there for what seems like 2 minutes while fw_update inevitably fails before turning on dnscrypt-proxy. I’ve been running snapshots and that’s really dumb. Or is there a way to have unbound connect to a failover server when the default resolver isn’t responsive that I’m not aware of?-- -Luke
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
fw_update issue with colon in URL
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 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? Regards, Mabi
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=125783114503531=2 > Episode 5: The Firmware Strikes Back: > http://marc.info/?l=openbsd-misc=126775051500581=2 > Episode 6: Return of the Vendor: > http://marc.info/?l=openbsd-misc=128779369427908=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=125783114503531=2 Episode 5: The Firmware Strikes Back: http://marc.info/?l=openbsd-misc=126775051500581=2 Episode 6: Return of the Vendor: http://marc.info/?l=openbsd-misc=128779369427908=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.
fw_update verify firmware?
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 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.
fw_update long timeout, how to specify mirror
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. # 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 :( /T
syspatch(8) and patches requiring fw_update
In the latest mds errata patch, I noticed that one of the steps is to run fw_update. From briefly looking over the syspatch script, I don't see it calling fw_update once a patch is applied. Would you welcome a diff to add support for this? If so I can look at writing one. It would check against the .sig patch file itself, since the .tgz syspatch binary patch doesn't contain any details about needing to run fw_update. A rough set of steps would be: - Pull .sig patch from mirror and verify signature - Parse for fw_update - Once the patch has been applied, run fw_update Please let me know of any feedback to this approach. Andrew
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.
fw_update signify unsigned package on current and 6.2-stable
Hello:
A couple of month ago, I decided to take the plunge and setup an openbsd laptop.
I bought a relatively newer ThinkPad, and (a couple of months ago) set it up and
started playing with the desktop environment.
Well, life happened, and I put it aside for a while. Yesterday, I decided to
look at it again, and decided I would just start over.
So, I downloaded the current install image, and installed it on the laptop.
This laptop has no wired Ethernet port, just wireless which requires the
iwm-firmware.
So, after installing -current and booting into the system, I plugged in a USB
drive with the "iwm-firmware-0.20170105.tgz" on it, and issued:
# fw_update -p /mnt iwm
This worked a couple of months ago, and the wireless came up. Yesterday (and
today), I got/get:
file:/mnt/iwm-firmware-0.20170105.tgz: unsigned package (signify(1) doesn't see
old-style signatures)
I see that how signify works had recently changed, so, I reinstalled with the
6.2 stable image.
But, I get the same error.
I would rather not go all the way back to 6.1.
I can find no way in the man page to get fw_update to install without checking
signatures. I did try using "pkg_add -D unsigned" as a guess (with little
hope), but that did not work either.
It seems that the firmware package ("20170105") is from the time before signify
changed, and has not been brought into sync with the new signify (that's just a
guess).
How do I install the iwm-firmware without a network connection on either
6.2-stable or -current?
Thanks
Ted
---
This email has been checked for viruses by AVG.
http://www.avg.com
Re: some more info on pkg_add/fw_update changes
On Tue, Oct 04, 2016 at 03:15:18PM +0200, Marc Espie wrote: > - the new scheme is slightly more unflexible with respect to unsigned > data: by default, every .tgz is piped thru signify -Zs, so > pkg_add/pkg_info/fw_update WON'T even see any data if it's not signed. > Error reporting is inadequate, to say the least. I'm working on fixing > that, but there is some code I do not like, so there is a great deal of > rewrite. There was actually a trivial bug in some code, so that you should now get error reports that make sense, though slightly verbose. At the very least, you will now get 'unsigned packages' messages on localhost. I've also trimmed ftp/signify interactions a bit. > - I'm working on ways to mix unsigned and signed packages in a sane way. > I've added TRUSTED_PKG_PATH, and I will have a mechanism that says > some sources are safe (/usr/ports/packages/%a/all, for instance). > This is unnecessary if you only install official binary stuff, but it is > necessary for development or for people who really want to tinker with > their machines. /usr/ports/packages/%a/all is surprisingly difficult to normalize every time (File::Spec->abs2rel tends to yield the "wrong" location for me thx to /usr/ports being a symlink), so this is likely not to happen.
some more info on pkg_add/fw_update changes
About a week ago, we switched to the new signing scheme by default. There are good reasons to bury the old signing scheme completely, so this is what's currently happening, there are some rough edges. Technically speaking, the new signatures are "outside", they're in the gzip header, and the only thing that sees them is signify -Zs. pkg_add/fw_update only ever sees "safe" input, so that all the data that will be gunzip'd/untared is already checked. This has some rough edges. - old snapshots will not see the new signatures at all (this is still a gzip archive with transparent information) and report everything as unsigned. - the new scheme is slightly more unflexible with respect to unsigned data: by default, every .tgz is piped thru signify -Zs, so pkg_add/pkg_info/fw_update WON'T even see any data if it's not signed. Error reporting is inadequate, to say the least. I'm working on fixing that, but there is some code I do not like, so there is a great deal of rewrite. - I'm still in the process of taking out old signatures entirely. Pretty soon, the only place it will still be around is that packing-lists may still contain old signatures... necessary for old installed packages that don't change that often. Again, rough edges. - I'm working on ways to mix unsigned and signed packages in a sane way. I've added TRUSTED_PKG_PATH, and I will have a mechanism that says some sources are safe (/usr/ports/packages/%a/all, for instance). This is unnecessary if you only install official binary stuff, but it is necessary for development or for people who really want to tinker with their machines. - pkg_sign lost the ability to sign distant sources temporarily.
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=147283361813517=2
fw_update stops with Fatal error: Unsigned package ...
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 real mem = 8029429760 (7657MB) avail mem = 7781588992 (7421MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xeebc0 (57 entries) bios0: vendor LENOVO version "9VKT33AUS" date 09/11/2013 bios0: LENOVO 1990RZ2 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC TCPA MCFG SLIC MCFG HPET SSDT acpi0: wakeup devices PCE2(S4) PCE3(S4) PCE4(S4) PCE5(S4) PCE6(S4) PCE7(S4) PCE9(S4) PCEA(S4) PCEB(S4) PCEC(S4) SBAZ(S4) P0PC(S4) PE20(S4) PE21(S4) PE22(S4) PE23(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Athlon(tm) II X2 B26 Processor, 3193.48 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,NODEID,ITSC cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB 64b/line 16-way L2 cache cpu0: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative cpu0: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative cpu0: AMD erratum 721 detected and fixed cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 199MHz cpu0: mwait min=64, max=64, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD Athlon(tm) II X2 B26 Processor, 3192.02 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,NODEID,ITSC cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB 64b/line 16-way L2 cache cpu1: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative cpu1: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative cpu1: AMD erratum 721 detected and fixed cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 3 pa 0xfec0, version 21, 24 pins acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpimcfg1 at acpi0 addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318180 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (P0P1) acpiprt2 at acpi0: bus -1 (PCE2) acpiprt3 at acpi0: bus -1 (PCE3) acpiprt4 at acpi0: bus -1 (PCE4) acpiprt5 at acpi0: bus -1 (PCE5) acpiprt6 at acpi0: bus -1 (PCE6) acpiprt7 at acpi0: bus -1 (PCE7) acpiprt8 at acpi0: bus -1 (PCE9) acpiprt9 at acpi0: bus -1 (PCEA) acpiprt10 at acpi0: bus 2 (P0PC) acpiprt11 at acpi0: bus 3 (PE20) acpiprt12 at acpi0: bus -1 (PE21) acpiprt13 at acpi0: bus -1 (PE22) acpiprt14 at acpi0: bus 4 (PE23) acpicpu0 at acpi0: C1(@1 halt!), PSS acpicpu1 at acpi0: C1(@1 halt!), PSS "PNP0501" at acpi0 not configured tpm0 at acpi0: TPM_ addr 0xfed4/0x5000: device 0x104a rev 0x4e acpibtn0 at acpi0: PWRB cpu0: 3193 MHz: speeds: 3200 2500 1900 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "AMD RS880 Host" rev 0x00 ppb0 at pci0 dev 1 function 0 unknown vendor 0x17aa product 0x9602 rev 0x00 pci1 at ppb0 bus 1 radeondrm0 at pci1 dev 5 function 0 "ATI Radeon HD 4250" rev 0x00 drm0 at radeondrm0 radeondrm0: apic 3 int 18 ahci0 at pci0 dev 17 function 0 "ATI SBx00 SATA" rev 0x00: apic 3 int 19, AHCI 1.2 ahci0: port 0: 3.0Gb/s ahci0: port 1: 1.5Gb/s scsibus1 at ahci0: 32 targets sd0 at scsibus1 targ 0 lun 0: <ATA, WDC WD3200AAKS-0, 40.0> SCSI3 0/direct fixed naa.50014ee1018094dc sd0: 305245MB, 512 bytes/sector, 625142448 sectors cd0 at scsibus1 targ 1 lun 0: <PLDS, DVD-RW DH16ABSH, YL32> ATAPI 5/cdrom removable ohci0 at pci0 dev 18 function 0 "ATI SB700 USB" rev 0x00: apic 3 int 18, version 1.0, legacy support ehci0 at pci0 dev 18 function 2 "ATI SB700 USB2" rev 0x00: apic 3 int 17 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 configuration 1 interface 0 "ATI EHCI root hub" rev 2.00/1.00 addr 1 ohci1 at pci0 dev 19 function 0 "ATI SB700 USB" rev 0x00: apic 3 int 18, version 1.0, legacy support ehci1 at pci0 dev 19 function 2 "ATI SB700 USB2" rev 0x00: apic 3 int 17 usb1 at ehci1: USB revisi
5.4 fw_update firmware path
Hello, The path for firmware files used by fw_update needs to be updated for 5.4, otherwise a manual install is necesary. Thank you.
Re: 5.4 fw_update firmware path
Please elaborate. I'm sorry for the quick suggestion. Here are the details... I was installing from snapshots and the fw_update was run at first boot. I was using bge0 for network connection in a hope that the firmware for iwi0 will be installed. I got a message, then when I was trying to use iwi0 I got the famous kernel 'can't load firmware ' I was connecting again bge0 and run fw_update, but no files were installed in /etc/firmware so I was looking at the script code and saw there is a path to http://firmware.openbsd.org/firmare/$version/. I am using 5.4, the 5.4 branch cannot be reached since this is not created there yet. I exported the path manually and installed by hand using pkg_add. Not a big deal, but for a beginner this cannot be very easy. I think you need to create a subdirectory named 5.4 and put firmware there for. I hope I got it right this time.
Re: 5.4 fw_update firmware path
On 07/19/13 18:01, Mihai Popescu wrote: Hello, The path for firmware files used by fw_update needs to be updated for 5.4, otherwise a manual install is necesary. Thank you. Are you suggesting there are more non-free firmwares that we don't automagically fetch? Please elaborate.
Re: 5.4 fw_update firmware path
On 07/19/13 19:22, Mihai Popescu wrote: Please elaborate. I'm sorry for the quick suggestion. Here are the details... I was installing from snapshots and the fw_update was run at first boot. I was using bge0 for network connection in a hope that the firmware for iwi0 will be installed. I got a message, then when I was trying to use iwi0 I got the famous kernel 'can't load firmware ' I was connecting again bge0 and run fw_update, but no files were installed in /etc/firmware so I was looking at the script code and saw there is a path to http://firmware.openbsd.org/firmare/$version/. I am using 5.4, the 5.4 branch cannot be reached since this is not created there yet. I exported the path manually and installed by hand using pkg_add. Not a big deal, but for a beginner this cannot be very easy. I think you need to create a subdirectory named 5.4 and put firmware there for. I hope I got it right this time. You surely did, thanks for taking the time to explain. /Alexander
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 mark.sulli...@gmx.fr 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
* David Coppa dco...@gmail.com [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: 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 mark.sulli...@gmx.fr wrote:
Re: fw_update
On Thu, May 10, 2012 at 2:34 AM, Brett brett.ma...@gmx.com 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
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 : 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: Re : Re: fw_update
On Thu, May 10, 2012 at 12:03 PM, mark sullivan mark.sulli...@gmx.fr 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 : 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: 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: 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
On Wed, May 9, 2012 at 3:33 PM, mark sullivan mark.sulli...@gmx.fr 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
fw_update
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
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.
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 tob...@trustedco.de 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, 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
Il giorno 09/mag/2012 21:38, mark sullivan mark.sulli...@gmx.fr 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 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 Sarnowskitob...@trustedco.de 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 2012-05-09, mark sullivan mark.sulli...@gmx.fr 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
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 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
On Thu, 10 May 2012 00:55:07 + Ted Unangst t...@tedunangst.com 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 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 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
Ah, ok. Sorry Mark. I didn't know that. Johan On May 10, 2012 12:46 AM, Alexander Hall ha...@openbsd.org 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 Sarnowskitob...@trustedco.de** 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.
