Can binary patches from openbsd.org.mx be trusted?
Contributed by
phessler
on
from the they are out to get me dept.
chas asks "Gee I love not having to compile patches from source. Binary patches from http://tuxtla.openbsd.org.mx/pub/binpatch/ are WAY too convenient. I'm currious, though, has anyone had problems with their methods, or any suspicion (with grounds) that their binaries differ significantly from what would be produced with a stock compile?"
While this question may be controversial, I feel it is an important question to ask. To the best of my knowledge there hasn't been any security issues with these binary patches, but better safe than sorry.
(Comments are closed)
Comments
By
Anonymous Coward (195.217.242.33)
on
I guess the advantage to patching is that you can see what code is being patched and what changes are being introduced. You also *should* know where you're original base code comes from.
If you don't know anything about code etc. a binary solution might be just as good to you as a patch. However adopting this approach you need to be very cautious.
By
mike (217.162.136.179)
on
I've used the patches for 3.3/4 on test systems, I also downloaded the build subsystem and tried to roll my own since at some point they weren't kept up to date (they are again now I think), nothing seemed wrong from a cursory examination.
I ran into some trouble rolling my own but I assume this was due more to a lack of time, commitment and/or intelligence on my part.
I also assume that I would notice if something *were* wrong.
But I can't really see the theoretical difference between this and trusting your favourite cvs mirror to be magically immune to problems, errors, determined adversaries, solar flares and whatnot.
see http://www.openbsd.org/errata.html#cvs
you just have to place your trust somewhere along the line... why not with our mexican friends?
p.s. if obsd really goes after the mid-range router market, then something like this would certainly deserve a more "official" status IMHO
By
click46 (67.127.250.194) click46@genmay.net
on
I perused the openbsd.org.mx site but didn't find any documentation on how they run their binary patch system. anyone?
By
Daniel Farrugia (3ffe:bc0:56d:0:2d2d:69ac:7aa1:35d8)
on
I think you can only trust binary patches from an unknown source to a certain degree, for instance I run openbsd on my firewall and cannot trust "unofficial" binary patches on such a sensitive system. However the firewall doesn't have enough resources to compile the patched sources -- a convenient solution which works for me is to install openbsd on my XP desktop machine using VMWare and compile everything from there.
By
Anonymous Coward (148.233.228.53)
on
not that so surely it can be, but my doubt, is not easy to use: config MYKERNEL; make depend; make; cp bsd /bsd; reboot?????? now bitpatch and later??? rpm??
By
Steven (65.94.161.21)
on
Like Mike said, we can't mistrust everybody. However, the following issue should be considered : how do we know that something called City X OpenBSD User Group or simply OpenBSD mirror is legitimate ? Is there anyone in Theo's team who can vouch for them ?
The mexican web site provides a convenient shortcut but I don't use it : it reminds me of Stephanie (the security patch, not some chicks).
starting with a proof of concept that transformed later into the binpatch framework. Since then, I build binary patches to keep the servers at work up to date, and publish them at people request.
I build i386 binary patches only for the last two releases of OpenBSD on VMWare, on a PC at work. This PC is for my own use only, nobody else has access to it. Unfortunately I can't make them at home since I can't afford a decent (ADSL 256Kbps) Internet connection. I used to upload them with a 56 Kbps modem (at 2KBps upload) but it's terrible slow. BTW, if anybody out there can employ me, I'd like to hear from you. Salaries in Mexico suck.
Since 2003, Lizardo, a friend of mine and member of OpenBSD México, is building binary patches for sparc64. Details about it can be found at
http://www.openbsd.org.mx/es/projects/binpatch/sparc64.html. He can be reached at lizardo at openbsd.org.mx
These binary patches are unofficial of course, I have always taken care to say it. You can trust them as much as you trust me. They are the same I use to patch all the OpenBSD systems I'm in charge, including tuxtla.openbsd.org.mx. It would certainly be great that the OpenBSD project releases binary patches, although I don't think it will happen any time soon, they have a lot of work already.
Considering the unadulterated simplicity of applying patches to an OpenBSD machine, why risk a binary patch?
Comments
By
chas (12.217.90.112)
on
1. An inaccessible system is installed without a compiler.
2. It's not so simple when you don't maintain the entire source tree.
3. Slow cpu.
4. The number of patches begins to overwhelm. 3.3 went maybe 4 months with no patches; that record hasn't even been approached lately.
Comments
By
Anonymous Coward (213.118.72.99)
on
The number of patches in 3.5 isn't really overwhelming...
001 - nothing to patch, unless you use that particular pkg on macppc
002 - cvs. count++
003 - going to build a new kernel, but not quite yet :)
004 - kernel.
005 - kernel, again.
006 - kernel, last one, allright, build it. count++
So, although there are 6 patches for 3.5, you only have to build 2 things: cvs and one kernel (when installing a new machine).
How do binary patches cope with this? It seems that you'd end up with 4 kernels, of which you really only need the last one.
This problem isn't really specific to the kernel. It's possible that more than one patch would concern a same application, although that's far less likely than a few kernel patches.
By
Anonymous Coward (195.217.242.33)
on
I agree
keeping the code and the implementation seperate doesn't seem like a bad idea either.
By Anonymous Coward (195.217.242.33) on
If you don't know anything about code etc. a binary solution might be just as good to you as a patch. However adopting this approach you need to be very cautious.
By mike (217.162.136.179) on
By click46 (67.127.250.194) click46@genmay.net on
Comments
By Ryan Briones (65.240.134.254) on
http://tuxtla.openbsd.org.mx/~santana/binpatch.html
Comments
By click46 (68.65.242.163) on
By Daniel Farrugia (3ffe:bc0:56d:0:2d2d:69ac:7aa1:35d8) on
By Anonymous Coward (148.233.228.53) on
By Steven (65.94.161.21) on
Comments
By lcde (141.106.202.124) sidabraj@nsgcorp.net on
Comments
By Anonymous Coward (82.39.96.34) on
By Gerardo Santana Gómez Garrido (148.223.128.3) santana at openbsd.org.mx on http://www.openbsd.org.mx/~santana/
Binary patches development started in 2001
http://www.monkey.org/openbsd/archive/misc/0106/msg01721.html
http://marc.theaimsgroup.com/?l=openbsd-misc&m=99365270528488&w=2
starting with a proof of concept that transformed later into the binpatch framework. Since then, I build binary patches to keep the servers at work up to date, and publish them at people request.
I build i386 binary patches only for the last two releases of OpenBSD on VMWare, on a PC at work. This PC is for my own use only, nobody else has access to it. Unfortunately I can't make them at home since I can't afford a decent (ADSL 256Kbps) Internet connection. I used to upload them with a 56 Kbps modem (at 2KBps upload) but it's terrible slow. BTW, if anybody out there can employ me, I'd like to hear from you. Salaries in Mexico suck.
Since 2003, Lizardo, a friend of mine and member of OpenBSD México, is building binary patches for sparc64. Details about it can be found at http://www.openbsd.org.mx/es/projects/binpatch/sparc64.html. He can be reached at lizardo at openbsd.org.mx
These binary patches are unofficial of course, I have always taken care to say it. You can trust them as much as you trust me. They are the same I use to patch all the OpenBSD systems I'm in charge, including tuxtla.openbsd.org.mx. It would certainly be great that the OpenBSD project releases binary patches, although I don't think it will happen any time soon, they have a lot of work already.
BTW, Lizardo has just pointed me to a script by Frank Sweetser for automating binary updates from binpatch: http://www.giac.org/practical/GSNA/Frank_Sweetser_GSNA.pdf
Comments
By LinuXo (200.77.145.119) garciarojas@NOSPAMgulmich.org on http://linuxo.gulmich.org
By Anonymous Coward (24.10.175.113) on
Comments
By chas (12.217.90.112) on
2. It's not so simple when you don't maintain the entire source tree.
3. Slow cpu.
4. The number of patches begins to overwhelm. 3.3 went maybe 4 months with no patches; that record hasn't even been approached lately.
Comments
By Anonymous Coward (213.118.72.99) on
001 - nothing to patch, unless you use that particular pkg on macppc
002 - cvs. count++
003 - going to build a new kernel, but not quite yet :)
004 - kernel.
005 - kernel, again.
006 - kernel, last one, allright, build it. count++
So, although there are 6 patches for 3.5, you only have to build 2 things: cvs and one kernel (when installing a new machine).
How do binary patches cope with this? It seems that you'd end up with 4 kernels, of which you really only need the last one.
This problem isn't really specific to the kernel. It's possible that more than one patch would concern a same application, although that's far less likely than a few kernel patches.
By Anonymous Coward (195.217.242.33) on
keeping the code and the implementation seperate doesn't seem like a bad idea either.