Re: SHA256.sig not contained in install62.iso
Leroy, You can use any mirror as long as the mirror contains the patches for your version and architecture, mirrors should have identical content (once they are all synced ) ... you can change PKG_PATH at anytime (except when installing something ) I hope this helps On 22 February 2018 at 20:41, leroy jordan wrote: > So what can you do if the installurl file dose not mach the mirror site > that you downloaded the iso from. In my case I download it from New York > however I have Sonic which is San Francisco. > > On Feb 22, 2018 7:36 AM, "Marcus MERIGHI" wrote: > >> t...@equalit.ie (tomr), 2018.02.22 (Thu) 12:35 (CET): >> > On 02/21/18 04:39, Kevin Chadwick wrote: >> > > On Tue, 20 Feb 2018 19:23:05 +0200 >> > > >> > > >> > >> Isn't the same true when I download file sets from any mirror? After >> > >> all I download SHA256.sig abd file sets from mirror, how can I trust >> > >> it? >> > > >> > > I am not a developer but my take is that they do not want to tell you >> it >> > > is verified if you have been given a CD etc.. Anything could have been >> > > booted and tell you it is verified. >> > > >> > > You can verify the .iso manually and you can use e.g. isomaster to add >> > > sha256.sig to the CD in which case it will verify them. I have used >> > > this in the past as a scratched rw seemingly fails sooner on verify >> than >> > > reading and also won't try to upgrade. >> > > >> > > If you have already manually verified bsd.rd and booted from that as I >> > > and I guess most developers do most often when upgrading then you do >> > > want it to tell you the http retrieval verified. >> > > >> > > I guess it was the simplest way considering installer size >> > > constraints/battles to avoid misinforming the user. >> > > >> > >> > I have a little snapshot upgrade script which: >> > >> > - downloads snapshots/amd64/SHA256.sig from a mirror >> > - compares that against my latest local copy, exits if they are the same >> > (ie no new snapshot) >> > - TODO: grabs SHA256.sig from ftp.openbsd.org and compares, exits if the >> > mirror is not in sync >> > - downloads snapshots/amd64/installXX.fs from the mirror >> > - verifies installXX.fs with signify >> > - vnd mounts installXX.fs and copies the files to where I expect them >> > for upgrade >> > - copies the (now verified) SHA256.sig into place >> > - copies the latest bsd.rd to / so I can boot from it >> > - informs me that a new snapshot is ready to install >> > >> > It's not cron'ed, I just run it when I feel like maybe upgrading. >> > >> > Somewhere on the todo list is to figure out how to build a custom bsd.rd >> > containing auto_upgrade.conf so that it's more or less automatic (works >> > great for local VMs, but I don't always control the upstream DHCP server >> > and anyway iwm firmware isn't ready at that point in the installer). >> >> >> Information for inst:upobsd-0.0.20180106 >> >> Comment: >> download, verify and patch bsd.rd image >> >> Description: >> upobsd is a ksh(1) script designed to download, verify and optionally patch >> bsd.rd image. >> >> upobsd will download bsd.rd image using ftp(1) from mirror defined in >> installurl(5), will verify the downloaded file using signify(1) and local >> key >> inside /etc/signify to ensure integrity, and optionally patch the image for >> adding auto_install.conf or auto_upgrade.conf file to add support of >> offline >> autoinstall(8). >> >> Maintainer: Sebastien Marie >> >> WWW: https://bitbucket.org/semarie/upobsd >> >> >> Marcus >> >> -- Kindest regards, Tom Smyth Mobile: +353 87 6193172 The information contained in this E-mail is intended only for the confidential use of the named recipient. If the reader of this message is not the intended recipient or the person responsible for delivering it to the recipient, you are hereby notified that you have received this communication in error and that any review, dissemination or copying of this communication is strictly prohibited. If you have received this in error, please notify the sender immediately by telephone at the number above and erase the message You are requested to carry out your own virus check before opening any attachment.
Re: SHA256.sig not contained in install62.iso
So what can you do if the installurl file dose not mach the mirror site that you downloaded the iso from. In my case I download it from New York however I have Sonic which is San Francisco. On Feb 22, 2018 7:36 AM, "Marcus MERIGHI" wrote: > t...@equalit.ie (tomr), 2018.02.22 (Thu) 12:35 (CET): > > On 02/21/18 04:39, Kevin Chadwick wrote: > > > On Tue, 20 Feb 2018 19:23:05 +0200 > > > > > > > > >> Isn't the same true when I download file sets from any mirror? After > > >> all I download SHA256.sig abd file sets from mirror, how can I trust > > >> it? > > > > > > I am not a developer but my take is that they do not want to tell you > it > > > is verified if you have been given a CD etc.. Anything could have been > > > booted and tell you it is verified. > > > > > > You can verify the .iso manually and you can use e.g. isomaster to add > > > sha256.sig to the CD in which case it will verify them. I have used > > > this in the past as a scratched rw seemingly fails sooner on verify > than > > > reading and also won't try to upgrade. > > > > > > If you have already manually verified bsd.rd and booted from that as I > > > and I guess most developers do most often when upgrading then you do > > > want it to tell you the http retrieval verified. > > > > > > I guess it was the simplest way considering installer size > > > constraints/battles to avoid misinforming the user. > > > > > > > I have a little snapshot upgrade script which: > > > > - downloads snapshots/amd64/SHA256.sig from a mirror > > - compares that against my latest local copy, exits if they are the same > > (ie no new snapshot) > > - TODO: grabs SHA256.sig from ftp.openbsd.org and compares, exits if the > > mirror is not in sync > > - downloads snapshots/amd64/installXX.fs from the mirror > > - verifies installXX.fs with signify > > - vnd mounts installXX.fs and copies the files to where I expect them > > for upgrade > > - copies the (now verified) SHA256.sig into place > > - copies the latest bsd.rd to / so I can boot from it > > - informs me that a new snapshot is ready to install > > > > It's not cron'ed, I just run it when I feel like maybe upgrading. > > > > Somewhere on the todo list is to figure out how to build a custom bsd.rd > > containing auto_upgrade.conf so that it's more or less automatic (works > > great for local VMs, but I don't always control the upstream DHCP server > > and anyway iwm firmware isn't ready at that point in the installer). > > > Information for inst:upobsd-0.0.20180106 > > Comment: > download, verify and patch bsd.rd image > > Description: > upobsd is a ksh(1) script designed to download, verify and optionally patch > bsd.rd image. > > upobsd will download bsd.rd image using ftp(1) from mirror defined in > installurl(5), will verify the downloaded file using signify(1) and local > key > inside /etc/signify to ensure integrity, and optionally patch the image for > adding auto_install.conf or auto_upgrade.conf file to add support of > offline > autoinstall(8). > > Maintainer: Sebastien Marie > > WWW: https://bitbucket.org/semarie/upobsd > > > Marcus > >
Re: SHA256.sig not contained in install62.iso
t...@equalit.ie (tomr), 2018.02.22 (Thu) 12:35 (CET): > On 02/21/18 04:39, Kevin Chadwick wrote: > > On Tue, 20 Feb 2018 19:23:05 +0200 > > > > > >> Isn't the same true when I download file sets from any mirror? After > >> all I download SHA256.sig abd file sets from mirror, how can I trust > >> it? > > > > I am not a developer but my take is that they do not want to tell you it > > is verified if you have been given a CD etc.. Anything could have been > > booted and tell you it is verified. > > > > You can verify the .iso manually and you can use e.g. isomaster to add > > sha256.sig to the CD in which case it will verify them. I have used > > this in the past as a scratched rw seemingly fails sooner on verify than > > reading and also won't try to upgrade. > > > > If you have already manually verified bsd.rd and booted from that as I > > and I guess most developers do most often when upgrading then you do > > want it to tell you the http retrieval verified. > > > > I guess it was the simplest way considering installer size > > constraints/battles to avoid misinforming the user. > > > > I have a little snapshot upgrade script which: > > - downloads snapshots/amd64/SHA256.sig from a mirror > - compares that against my latest local copy, exits if they are the same > (ie no new snapshot) > - TODO: grabs SHA256.sig from ftp.openbsd.org and compares, exits if the > mirror is not in sync > - downloads snapshots/amd64/installXX.fs from the mirror > - verifies installXX.fs with signify > - vnd mounts installXX.fs and copies the files to where I expect them > for upgrade > - copies the (now verified) SHA256.sig into place > - copies the latest bsd.rd to / so I can boot from it > - informs me that a new snapshot is ready to install > > It's not cron'ed, I just run it when I feel like maybe upgrading. > > Somewhere on the todo list is to figure out how to build a custom bsd.rd > containing auto_upgrade.conf so that it's more or less automatic (works > great for local VMs, but I don't always control the upstream DHCP server > and anyway iwm firmware isn't ready at that point in the installer). Information for inst:upobsd-0.0.20180106 Comment: download, verify and patch bsd.rd image Description: upobsd is a ksh(1) script designed to download, verify and optionally patch bsd.rd image. upobsd will download bsd.rd image using ftp(1) from mirror defined in installurl(5), will verify the downloaded file using signify(1) and local key inside /etc/signify to ensure integrity, and optionally patch the image for adding auto_install.conf or auto_upgrade.conf file to add support of offline autoinstall(8). Maintainer: Sebastien Marie WWW: https://bitbucket.org/semarie/upobsd Marcus
Re: SHA256.sig not contained in install62.iso
On 02/21/18 04:39, Kevin Chadwick wrote: > On Tue, 20 Feb 2018 19:23:05 +0200 > > >> Isn't the same true when I download file sets from any mirror? After >> all I download SHA256.sig abd file sets from mirror, how can I trust >> it? > > I am not a developer but my take is that they do not want to tell you it > is verified if you have been given a CD etc.. Anything could have been > booted and tell you it is verified. > > You can verify the .iso manually and you can use e.g. isomaster to add > sha256.sig to the CD in which case it will verify them. I have used > this in the past as a scratched rw seemingly fails sooner on verify than > reading and also won't try to upgrade. > > If you have already manually verified bsd.rd and booted from that as I > and I guess most developers do most often when upgrading then you do > want it to tell you the http retrieval verified. > > I guess it was the simplest way considering installer size > constraints/battles to avoid misinforming the user. > I have a little snapshot upgrade script which: - downloads snapshots/amd64/SHA256.sig from a mirror - compares that against my latest local copy, exits if they are the same (ie no new snapshot) - TODO: grabs SHA256.sig from ftp.openbsd.org and compares, exits if the mirror is not in sync - downloads snapshots/amd64/installXX.fs from the mirror - verifies installXX.fs with signify - vnd mounts installXX.fs and copies the files to where I expect them for upgrade - copies the (now verified) SHA256.sig into place - copies the latest bsd.rd to / so I can boot from it - informs me that a new snapshot is ready to install It's not cron'ed, I just run it when I feel like maybe upgrading. Somewhere on the todo list is to figure out how to build a custom bsd.rd containing auto_upgrade.conf so that it's more or less automatic (works great for local VMs, but I don't always control the upstream DHCP server and anyway iwm firmware isn't ready at that point in the installer). t
Re: SHA256.sig not contained in install62.iso
m8il1i...@gmail.com (Kevin Chadwick), 2018.02.21 (Wed) 19:07 (CET): > On Wed, 21 Feb 2018 10:10:30 +0100 > > > > I know this is a little bit farfetched, pardon my ignorence, but > > OpenBSD seeems vulnerable on first installation. In case of DNS > > poisoning, what can stop a virus from forwarding the installer to a > > false SHA256.sig and false repository? My guess would be to use > > DNSSEC and a local copy of an OpenBSD repository to avoid such issue. > > > > If you boot an unverified iso, then what is to stop it replacing your > bios? > > Authentication is always boot strapped by manual processes, including > your resolver key! Also DNSSEC is rarely used and mostly RSA 1024 bit. > > ecdsa will hopefully get more adoption than RSA has depite I believe > persisting to enable amplification albeit to a far smaller degree. > > T-shirts of keys were made and can be found in various places including > youtube, worn by developers etc., so that you can verify the iso file > before booting it. https://marc.info/?m=151103166108846 http://www.ebay.ca/itm/Official-OpenBSD-6-2-CD-Set/253265944606 https://i.ebayimg.com/images/g/fS4AAOSwH-daEH6S/s-l1600.jpg yet another source to compare ;-) Marcus
Re: SHA256.sig not contained in install62.iso
On Wed, Feb 21, 2018 at 4:10 AM, Jean-Michel Pouré wrote: > I know this is a little bit farfetched, pardon my ignorence, but > OpenBSD seeems vulnerable on first installation. In case of DNS > poisoning, what can stop a virus from forwarding the installer to a > false SHA256.sig and false repository? My guess would be to use > DNSSEC and a local copy of an OpenBSD repository to avoid such issue. > > Also I still don't understand the logic of not embedding SHA256.sig in > the ISO. A SHA256.sig exists, why NOT use it? This is not farfetched at all. If you obtain the ISO from an untrustworthy source, or you are misdirected to a false repository, then you cannot trust the ISO you receive. Likewise, you cannot trust any SHA256.sig file you receive. So, after you download SHA256.sig, you need a way to confirm that your copy of SHA256.sig is genuine, then once that's done you can verify whether your ISO is valid. This is what the signify tool does. It is small enough that you should be able to build it yourself on a machine you trust, and the OpenBSD pubkey that you need for SHA256.sig verification is small enough that you can key it in by hand if needed, and also small enough that you can visually confirm you have the correct key by comparing it with one from a trusted source (an original OpenBSD CD-ROM, a T-shirt, a picture you took during an OpenBSD presentation, etc.) The SHA256.sig that already exists can't be included in the ISO because it contains the signature of the ISO itself. So imagine you've made an ISO image, then you get the SHA256 hash of it, make and sign a SHA256.sig file`, but then you need to take this new file you've just created and put it into the ISO, which will cause the ISO's hash to change, invalidating the SHA256.sig you just created. So you would need to have two versions of SHA256.sig, one version that contains hashes for the ISO file (and also other 'installer' files like miniroot.fs and installNN.fs), and another SHA256.sig that contains hashes for the base sets (baseNN.tgz, compNN.tgz, gamesNN.tgz, etc.) and you would put the second SHA256.sig into the ISO, then create the first SHA256.sig later. For this to work (two SHA256.sig files with the same name but different content) you need to have two directories on all the mirrors, one for the file system images and another for bsd.rd and the sets, or you have to be ok with there being a file inside the ISO that doesn't match the same-named file available from the mirrors. In the end, since any SHA256.sig inside the ISO can't be trusted anyway unless you verified the ISO before you booted it, might as well just leave it out. The only time it's actually useful is if you are installing by booting a verified bsd.rd directly, and downloading the sets during installation (in which case the sets need to be verified after download). I suspect that it's really only for the benefit of people installing this way that the installer verifies SHA256.sig signatures at all. -ken
Re: SHA256.sig not contained in install62.iso
>On Tue, 20 Feb 2018 18:45:01 +0100 >Stefan Sperling wrote: > >> > I download SHA256.sig abd file sets from mirror, how can I trust it? >> >> You run a trusted signify binary, which was not obtained from the >> mirror but is part of your existing install, to check the signature >> on SHA256.sig. > >I know this is a little bit farfetched, pardon my ignorence, but >OpenBSD seeems vulnerable on first installation. In case of DNS >poisoning, what can stop a virus from forwarding the installer to a >false SHA256.sig and false repository? My guess would be to use >DNSSEC and a local copy of an OpenBSD repository to avoid such issue. > >Also I still don't understand the logic of not embedding SHA256.sig in >the ISO. A SHA256.sig exists, why NOT use it? Sometimes there's a vast difference between a person who declares something useful and easy to do, and the reality. Sometimes the person is just plain wrong.
Re: SHA256.sig not contained in install62.iso
On 2018-02-21, Jean-Michel Pouré wrote: > On Tue, 20 Feb 2018 18:45:01 +0100 > Stefan Sperling wrote: > >> > I download SHA256.sig abd file sets from mirror, how can I trust it? >> >> You run a trusted signify binary, which was not obtained from the >> mirror but is part of your existing install, to check the signature >> on SHA256.sig. > > I know this is a little bit farfetched, pardon my ignorence, but > OpenBSD seeems vulnerable on first installation. In case of DNS > poisoning, what can stop a virus from forwarding the installer to a > false SHA256.sig and false repository? My guess would be to use > DNSSEC and a local copy of an OpenBSD repository to avoid such issue. You can't avoid a bootstrap process somewhere. For software using PGP-signing, you need PGP utilities and the right public key. For OpenBSD you need the signify utility and the right public key (e.g. openbsd-62-base.pub). It doesn't matter if the SHA256.sig itself is intercepted because it's signed, when you check it with signify you can spot the modification and know not to trust it. So the main problem moves to getting a trusted signify public key. These are chained back to the first release where signify was used (e.g. go back to a 5.5 or later release from a trusted source, some of these are on CD, and release N includes the key for N+1). Because the keys are relatively short they can be sanely included in various media (you'll find photos and probably videos showing the key printed on some release CDs, plus plaintext mentions in mailing list posts, twitter, mastodon, etc - try searching for one of the public keys itself). untrusted comment: openbsd 6.0 base public key RWSho3oKSqgLQy+NpIhFXZJDtkE65tzlmtC24mStf8DoJd2OPMgna4u8 untrusted comment: openbsd 6.1 base public key RWQEQa33SgQSEsMwwVV1+GjzdcQfRNV2Bgo48Ztd2KiZ9bAodz9c+Maa untrusted comment: openbsd 6.2 base public key RWRVWzAMgtyg7g27STK1h1xA6RIwtjex6Vr5Y9q5SC5q5+b0GN4lLhfu untrusted comment: openbsd 6.3 base public key RWRxzbLwAd76ZZxHU7wuIFUOVGwl6SjNNzanKWTql8w+hui7WLE/72mW > Also I still don't understand the logic of not embedding SHA256.sig in > the ISO. A SHA256.sig exists, why NOT use it? Apart from anything else: at the time the iso and fs files are generated, a SHA256.sig does *not* exist, that is done after the release is built, on a separate machine that only handles signing as part of a locked down process.
Re: SHA256.sig not contained in install62.iso
>If someone is able to provide a fake ISO, he will also provide fake >SHA256.sig and/or fake public key on the ISO. So there is no gain to >provide such material as people will think "it is safe" whereas it is >not. that is true. however, the real reason it isn't on the media is that internal signing followed by exterior signing doesn't work with the snapshot release sequence i follow. and since snapshots don't have the interior signing, neither do releases. not that it matters. it's a great time to raise a rather late flag to the user and say "hey, did you perform diligence?". late, because they've already booted the media. we can't do much before they boot, and the moment this occurs is easy for us.
Re: SHA256.sig not contained in install62.iso
On Wed, 21 Feb 2018 10:10:30 +0100 > I know this is a little bit farfetched, pardon my ignorence, but > OpenBSD seeems vulnerable on first installation. In case of DNS > poisoning, what can stop a virus from forwarding the installer to a > false SHA256.sig and false repository? My guess would be to use > DNSSEC and a local copy of an OpenBSD repository to avoid such issue. > If you boot an unverified iso, then what is to stop it replacing your bios? Authentication is always boot strapped by manual processes, including your resolver key! Also DNSSEC is rarely used and mostly RSA 1024 bit. ecdsa will hopefully get more adoption than RSA has depite I believe persisting to enable amplification albeit to a far smaller degree. T-shirts of keys were made and can be found in various places including youtube, worn by developers etc., so that you can verify the iso file before booting it.
Re: SHA256.sig not contained in install62.iso
On Wed, Feb 21, 2018 at 10:10:30AM +0100, Jean-Michel Pouré wrote: > > I know this is a little bit farfetched, pardon my ignorence, but > OpenBSD seeems vulnerable on first installation. In case of DNS > poisoning, what can stop a virus from forwarding the installer to a > false SHA256.sig and false repository? My guess would be to use > DNSSEC and a local copy of an OpenBSD repository to avoid such issue. the installer has enough material to check the cryptographic signature on SHA256.sig. If the downloaded file hasn't a valid signature (according to the public key the installer have) it will complains and not use it. > Also I still don't understand the logic of not embedding SHA256.sig in > the ISO. A SHA256.sig exists, why NOT use it? Because the installer has to trust the public key on the ISO. If someone is able to provide a fake ISO, he will also provide fake SHA256.sig and/or fake public key on the ISO. So there is no gain to provide such material as people will think "it is safe" whereas it is not. Thanks. -- Sebastien Marie
Re: SHA256.sig not contained in install62.iso
On Tue, 20 Feb 2018 18:45:01 +0100 Stefan Sperling wrote: > > I download SHA256.sig abd file sets from mirror, how can I trust it? > > You run a trusted signify binary, which was not obtained from the > mirror but is part of your existing install, to check the signature > on SHA256.sig. I know this is a little bit farfetched, pardon my ignorence, but OpenBSD seeems vulnerable on first installation. In case of DNS poisoning, what can stop a virus from forwarding the installer to a false SHA256.sig and false repository? My guess would be to use DNSSEC and a local copy of an OpenBSD repository to avoid such issue. Also I still don't understand the logic of not embedding SHA256.sig in the ISO. A SHA256.sig exists, why NOT use it? Best regards,
Re: SHA256.sig not contained in install62.iso
On Tue, Feb 20, 2018 at 07:23:05PM +0200, mazocomp wrote: > Isn't the same true when I download file sets from any mirror? No. > After all > I download SHA256.sig abd file sets from mirror, how can I trust it? You run a trusted signify binary, which was not obtained from the mirror but is part of your existing install, to check the signature on SHA256.sig. A signify binary inside installXX.iso can't be trusted to not lie about the integrity of contents of installXX.iso.
Re: SHA256.sig not contained in install62.iso
On Tue, 20 Feb 2018 19:23:05 +0200 > Isn't the same true when I download file sets from any mirror? After > all I download SHA256.sig abd file sets from mirror, how can I trust > it? I am not a developer but my take is that they do not want to tell you it is verified if you have been given a CD etc.. Anything could have been booted and tell you it is verified. You can verify the .iso manually and you can use e.g. isomaster to add sha256.sig to the CD in which case it will verify them. I have used this in the past as a scratched rw seemingly fails sooner on verify than reading and also won't try to upgrade. If you have already manually verified bsd.rd and booted from that as I and I guess most developers do most often when upgrading then you do want it to tell you the http retrieval verified. I guess it was the simplest way considering installer size constraints/battles to avoid misinforming the user.
Re: SHA256.sig not contained in install62.iso
On Tue, Feb 20, 2018 at 12:59:08PM +0100, Theo Buehler wrote: > On Tue, Feb 20, 2018 at 12:56:06PM +0100, Nicolas Schmidt wrote: > > Hi, > > > > I am finally getting around to upgrading 6.1->6.2. When I try to install > > from CD using the install62.iso image, the install script complains that it > > can't find SHA256.sig (indeed, it's on it). > > > > Is that supposed to happen? > > Yes. The last paragraph from > https://www.openbsd.org/faq/faq4.html#Download says: > > The installXX.iso and installXX.fs images do not contain an SHA256.sig > file, and the installer will complain that it can't check the > signatures. It is not possible for the installer to verify the sets with > these images. After all, if someone were to make a rogue installXX.iso > file, they could certainly change the installer to say the files were > legitimate. Thus, you must verify those installer downloads separately. > Isn't the same true when I download file sets from any mirror? After all I download SHA256.sig abd file sets from mirror, how can I trust it?
Re: SHA256.sig not contained in install62.iso
Sorry, I of course meant to say it‘s *not* on it. > Am 20.02.2018 um 12:56 schrieb Nicolas Schmidt : > > Hi, > > I am finally getting around to upgrading 6.1->6.2. When I try to install from > CD using the install62.iso image, the install script complains that it can't > find SHA256.sig (indeed, it's on it). > > Is that supposed to happen? > > Best, > Nicolas A. Schmidt
Re: SHA256.sig not contained in install62.iso
On Tue, Feb 20, 2018 at 12:56:06PM +0100, Nicolas Schmidt wrote: > Hi, > > I am finally getting around to upgrading 6.1->6.2. When I try to install from > CD using the install62.iso image, the install script complains that it can't > find SHA256.sig (indeed, it's on it). > > Is that supposed to happen? Yes. The last paragraph from https://www.openbsd.org/faq/faq4.html#Download says: The installXX.iso and installXX.fs images do not contain an SHA256.sig file, and the installer will complain that it can't check the signatures. It is not possible for the installer to verify the sets with these images. After all, if someone were to make a rogue installXX.iso file, they could certainly change the installer to say the files were legitimate. Thus, you must verify those installer downloads separately.
SHA256.sig not contained in install62.iso
Hi, I am finally getting around to upgrading 6.1->6.2. When I try to install from CD using the install62.iso image, the install script complains that it can't find SHA256.sig (indeed, it's on it). Is that supposed to happen? Best, Nicolas A. Schmidt
