Re: Dumbing down the recent SSL stuff for users
Em 06-06-2014 22:11, patric conant escreveu: So we knew that OpenSSL had some problems, indicated by the fact that they were blissfully unaware that Valgrind gave warnings when compiling their code, from the Debian debacle. They knew, just didn't care. Then Heartbleed came along, and people knew how bad things really were, and then members of the OpenBSD got together and started working hard on cleaning up and auditing the OpenSSL codebase, which lead to some other people going through through the changes for indications as to what sort of vulnerabilities the original had. That eventually lead to this most recent round of vulnerabilities which professional courtesy dictated that the affected parties get enough time to patch their offerings before public disclosure, except for the OpenBSD team. The cleanup didn't necessarily had anything to do with these disclosures. The fact is, that many people, not just OpenBSD developers, started actually looking the code. As a user I should probably just run snapshots to cut my window of vulnerability as much as possible, for the foreseeable future, as this problem's likely to get worse before it get's better, at the actual inclusion of LibreSSL in OpenBSD. Does this sound right, did I miss some important subtleties? That depends on your requirements. Snapshots can sometimes be broken. It happens. Also, the it's hard to follow current. If you can, and can deal with the problems that come with it, then ok. If not, you might just follow stable. You don't even need to apply and compile the patches, if you trust the guys at mtier. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: new OpenSSL flaws
Em 07-06-2014 00:04, Solar Designer escreveu: tools and ethics are separate things It seems like you got to the real issue now. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: new OpenSSL flaws
On Sat, 7 Jun 2014 07:04:47 +0400 Solar Designer so...@openwall.com wrote: To clarify and for the record: Being on the distros list is not mandatory to receive advance notification of security issues. The list is just a tool. People reporting security issues to the distros list are encouraged to also notify upstream projects/developers of the affected software, other affected distro vendors, and/or affected Open Source projects. You and others may want to know that – since yesterday – the OpenSSL wiki says otherwise. Quoting: If you would like advanced notice of vulnerabilities before they are released to the general public, then please join [http://oss-security.openwall.org/wiki/mailing-lists/distros Operating system distribution security contact lists] at OpenWall's OSS Security http://wiki.openssl.org/index.php?title=Security_Advisoriesdiff=1700oldid=1697
Re: new OpenSSL flaws
Le 07/06/2014 05:41, Eric Furman a écrit : On Fri, Jun 6, 2014, at 07:28 AM, Maxime Villard wrote: Le 06/06/2014 12:47, Eric Furman a écrit : On Fri, Jun 6, 2014, at 04:20 AM, Renaud Allard wrote: On 06/06/2014 05:18 AM, Eric Furman wrote: On Thu, Jun 5, 2014, at 08:36 PM, Giancarlo Razzolini wrote: Em 05-06-2014 21:23, David Goldsmith escreveu: Probably ipfilter http://christopher-technicalmusings.blogspot.com/2009/03/switching-firewalls-from-ipf-to-pf-on.html If it is indeed ipfilter, I don't think OpenSSL will have the same fate. There is lots of money on it, and even more now, that the Linux Foundation is funding them directly. I believe that LibreSSL and OpenSSL will live alongside for a long time. That's a valid opinion, but as I said, I doubt it. Vendors aren't stupid. With all that has happened lately, given a choice the switch will not take long. Given a choice, perhaps. But some will stick with OpenSSL only because they want the money given by FIPS certification. This is a joke, right? I think you are sadly misinformed. This is OPEN SOFTWARE. Vendors will choose the least problematic software. You are naive. Ah. I think you underestimate the intelligence of SSL Vendors. Free software is fantastic, we all benefit, but Vendors choose the best solutions. Given the current circumstances Libre.SSL WILL prevail. I HAD TO CHANGE MY PASSWORD AT ALL OF MY ONLINE BANKING ACCOUNTS! THEY KNOW THAT OPENSSL IS SHIT! HOW LONG DO YOU THINK THEY WILL CONTINUE TO USE SHITE FROM OPENSSL? THEY ARE NOT STUPID! Thank you Because LibreSSL is bug-free? You think that in only 2 months LibreSSL has become the least problematic SSL software, and that everyone should use this instead of the usual OpenSSL shit? You are trying to convince us that LibreSSL is secure, and that if there's a bug, it's because of OpenSSL. I just find it a bit too easy, especially when most of the OpenSSL shit is included in LibreSSL. That, is great, naive joke. (and I'm not blaming LibreSSL) Sorry for the rant. I think you must have missed my original post. I didn't. I claimed that within a year OpenSSL will be replaced. I said nothing about replacing it now or anytime very soon. LibreSSL is still a work in progress and when it is a finished product it may contain some of the same elements that are in OpenSSL, but that may not necessarily be true in the end. My point is that LibreSSL is being developed by the OpenBSD team. This team has a very long track record of producing very good code. Will there be no bugs in LibreSSL? I can't answer that question. But I will be confident that it will be superior to OpenSSL. What gives LibreSSL more credibility? There's almost nothing new or innovative in it; it's just a cleaned up copy of OpenSSL. There might be some changes in the future, but you can be sure that LibreSSL will lag behind OpenSSL - and most of the code will remain the same. Contributing code upstream would have been a way more productive approach; it would have given a better image of the OpenBSD team, more credibility, and people would have been tempted to look deeper at what those guys do, to then figure out that these things are potentially good products. But the devs preferred to fork and now blame people. So, no, I don't think LibreSSL will prevail, simply because it has - and will have - nothing new and because it has no credibility. (And I also think that no one gives a fuck about this discussion, so I suggest we stop here, or continue offlist)
Re: new OpenSSL flaws
On Sat, Jun 07, 2014 at 09:13:36AM +0200, Francois Ambrosini wrote: On Sat, 7 Jun 2014 07:04:47 +0400 Solar Designer so...@openwall.com wrote: Being on the distros list is not mandatory to receive advance notification of security issues. The list is just a tool. People reporting security issues to the distros list are encouraged to also notify upstream projects/developers of the affected software, other affected distro vendors, and/or affected Open Source projects. You and others may want to know that ??? since yesterday ??? the OpenSSL wiki says otherwise. Quoting: If you would like advanced notice of vulnerabilities before they are released to the general public, then please join [http://oss-security.openwall.org/wiki/mailing-lists/distros Operating system distribution security contact lists] at OpenWall's OSS Security http://wiki.openssl.org/index.php?title=Security_Advisoriesdiff=1700oldid=1697 Thanks for letting me know. I wasn't aware of this. I don't know whether this wiki edit is authoritative for the OpenSSL project, but if it is it means that there's greater assurance those on distros list will continue to receive advance notification, and indeed it's simpler for the OpenSSL project to be able to notify more distro vendors at once. I don't see it as contradictory to what I wrote (quoted above): it doesn't say that those who haven't joined will definitely not be notified. I guess OpenSSL will maintain an additional list of who to notify, besides the distros list. As I said before, I can't speak for the OpenSSL project, though - so these are just guesses. My personal opinion is that if OpenBSD doesn't join the distros list, yet wants LibreSSL to be notified of OpenSSL security issues, OpenSSL should be notifying LibreSSL directly. I think it'd be helpful if LibreSSL nominates specific contact persons for that, along with PGP keys to use, and informs the OpenSSL project of that. (Use of PGP was mandatory in the recent advance notification offered to distros list.) Once that has been done, you'd have (more) reason to complain if you're not notified next time (but I hope you will be). Alexander
Re: standard FAQ procedure ... in chroot
On 2014-06-06, sven falempin sven.falem...@gmail.com wrote:
Dear misc readers,
I try to understand why MAKEDEV is failing inside my chroot, while i
can manually create some dev with mknod .
Like:
SCRIPT ${DESTDIR}/dev/MAKEDEV dev/MAKEDEV
SPECIAL cd dev; sh MAKEDEV ramdisk
sh: stdin[1]: mknod: console: Invalid argument
sh: stdin[1]: mknod: tty: Invalid argument
AFAIK everything else is ok inside the CHROOT.
Help is welcome.
Your chroot is probably on a filesystem mounted with nodev.
Re: new OpenSSL flaws
On 07 Jun 2014, at 08:38, Maxime Villard m...@m00nbsd.net wrote: Contributing code upstream would have been a way more productive approach; It's already been stated that working with upstream is out of the question for at least the following reasons: * Bugs linger unattended for years. * The code style is next to unreadable for outsiders. * C security standards and best practices are severely lacking. * Upstream doesn't have the manpower to change any of this. And my favourite bit: * Upstream generates money by enforcing the above. It's a business model. From an economical standpoint a good one, but technologically, ethically and ideologically it's a disaster for our modern society that bases a lot of trust on OpenSSL. It's when open source effectively becomes broken source, and the only way to change that is to fork or rewrite. OpenSSL and everybody willing to use it will be able to benefit freely from LibReSSL efforts, given that they commit to improving their code base. A project that's not willing to improve on its own should, bluntly put, die as soon as possible. There is no reason to state your opinion about how OpenSSL should have been fixed given the facts that you chose to ignore. Consider the possibility that your view is wrong. And don't assume that LibReSSL is the right thing, it's just a thing. Well, a good thing. Definitely not a bad thing. I hope we can agree on that. Cheers, Franco
Re: standard FAQ procedure ... in chroot
On Sat, Jun 7, 2014 at 6:58 AM, Stuart Henderson s...@spacehopper.org wrote:
On 2014-06-06, sven falempin sven.falem...@gmail.com wrote:
Dear misc readers,
I try to understand why MAKEDEV is failing inside my chroot, while i
can manually create some dev with mknod .
Like:
SCRIPT ${DESTDIR}/dev/MAKEDEV dev/MAKEDEV
SPECIAL cd dev; sh MAKEDEV ramdisk
sh: stdin[1]: mknod: console: Invalid argument
sh: stdin[1]: mknod: tty: Invalid argument
AFAIK everything else is ok inside the CHROOT.
Help is welcome.
Your chroot is probably on a filesystem mounted with nodev.
nop , this mistake i did and already corrected. I can call a pipe |
or read /dev/(u)random etc... (i called MAKEDEV outside the chroot and
then enter it), but when inside...i have those Invalid argument.
i suspect a config file somewhere but i am in the dark.
--
-
() ascii ribbon campaign - against html e-mail
/\
Re: new OpenSSL flaws
Em 07-06-2014 03:38, Maxime Villard escreveu: But the devs preferred to fork and now blame people. So, no, I don't think LibreSSL will prevail, simply because it has - and will have - nothing new and because it has no credibility. You should really take a look at the source code. If you're simply lazy, then take a look at the cvsweb: http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/ This wasn't simple code deletion. They normalized the code with KNF. There were some new ciphers introduced. Lots of memory issues that OpenSSL has were and still are being solved. LibreSSL as it is now is already better than OpenSSL, by the simple fact that it has *less* code than it, so it has *less* bugs. It is possible some bugs were introduced by the changes? Probably. Time will tell. But if you take a look at OpenBSD's security track record, I willing to say that it will have few. The simple fact that they KNF'ed the code makes it easier for other people to read and find bugs. If you're not on tech@ then you don't know that this already happened, not just once, but several times in the past weeks. You should do your homework. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: new OpenSSL flaws
On 06/06/2014 10:04 PM, Solar Designer wrote: OpenBSD having declined to use the tool shouldn't be interpreted e.g. by OpenSSL as a reason not to notify LibreSSL directly. It seems worth noting that OpenBSD 5.5, the current release that many people are running, incorporates OpenSSL, not LibreSSL. There can't be really any question of OpenBSD users not being affected because they are using a forked version that might not be vulnerable; that fork is still in development. -- Matthew Weigel hacker unique idempot . ent
Re: standard FAQ procedure ... in chroot
On Sat, Jun 07, 2014 at 08:20:00AM -0400, sven falempin wrote:
On Sat, Jun 7, 2014 at 6:58 AM, Stuart Henderson s...@spacehopper.org wrote:
On 2014-06-06, sven falempin sven.falem...@gmail.com wrote:
Dear misc readers,
I try to understand why MAKEDEV is failing inside my chroot, while i
can manually create some dev with mknod .
Like:
SCRIPT ${DESTDIR}/dev/MAKEDEV dev/MAKEDEV
SPECIAL cd dev; sh MAKEDEV ramdisk
sh: stdin[1]: mknod: console: Invalid argument
sh: stdin[1]: mknod: tty: Invalid argument
AFAIK everything else is ok inside the CHROOT.
Help is welcome.
Your chroot is probably on a filesystem mounted with nodev.
nop , this mistake i did and already corrected. I can call a pipe |
or read /dev/(u)random etc... (i called MAKEDEV outside the chroot and
then enter it), but when inside...i have those Invalid argument.
i suspect a config file somewhere but i am in the dark.
Use set -x in the MAKEDV script to see what command fails.
Or just create the device nodes from a non-chrooted environment in the
right dir.
-Otto
Re: standard FAQ procedure ... in chroot
On Sat, Jun 7, 2014 at 11:30 AM, Otto Moerbeek o...@drijf.net wrote:
On Sat, Jun 07, 2014 at 08:20:00AM -0400, sven falempin wrote:
On Sat, Jun 7, 2014 at 6:58 AM, Stuart Henderson s...@spacehopper.org
wrote:
On 2014-06-06, sven falempin sven.falem...@gmail.com wrote:
Dear misc readers,
I try to understand why MAKEDEV is failing inside my chroot, while i
can manually create some dev with mknod .
Like:
SCRIPT ${DESTDIR}/dev/MAKEDEV dev/MAKEDEV
SPECIAL cd dev; sh MAKEDEV ramdisk
sh: stdin[1]: mknod: console: Invalid argument
sh: stdin[1]: mknod: tty: Invalid argument
AFAIK everything else is ok inside the CHROOT.
Help is welcome.
Your chroot is probably on a filesystem mounted with nodev.
nop , this mistake i did and already corrected. I can call a pipe |
or read /dev/(u)random etc... (i called MAKEDEV outside the chroot and
then enter it), but when inside...i have those Invalid argument.
i suspect a config file somewhere but i am in the dark.
Use set -x in the MAKEDV script to see what command fails.
i try right away , thanks
Or just create the device nodes from a non-chrooted environment in the
right dir.
it breaks the purpose
-Otto
--
-
() ascii ribbon campaign - against html e-mail
/\
Re: standard FAQ procedure ... in chroot
On Sat, Jun 07, 2014 at 12:14:55PM -0400, sven falempin wrote:
On Sat, Jun 7, 2014 at 11:30 AM, Otto Moerbeek o...@drijf.net wrote:
On Sat, Jun 07, 2014 at 08:20:00AM -0400, sven falempin wrote:
On Sat, Jun 7, 2014 at 6:58 AM, Stuart Henderson s...@spacehopper.org
wrote:
On 2014-06-06, sven falempin sven.falem...@gmail.com wrote:
Dear misc readers,
I try to understand why MAKEDEV is failing inside my chroot, while i
can manually create some dev with mknod .
Like:
SCRIPT ${DESTDIR}/dev/MAKEDEV dev/MAKEDEV
SPECIAL cd dev; sh MAKEDEV ramdisk
sh: stdin[1]: mknod: console: Invalid argument
sh: stdin[1]: mknod: tty: Invalid argument
AFAIK everything else is ok inside the CHROOT.
Help is welcome.
Your chroot is probably on a filesystem mounted with nodev.
nop , this mistake i did and already corrected. I can call a pipe |
or read /dev/(u)random etc... (i called MAKEDEV outside the chroot and
then enter it), but when inside...i have those Invalid argument.
i suspect a config file somewhere but i am in the dark.
Use set -x in the MAKEDV script to see what command fails.
i try right away , thanks
Or just create the device nodes from a non-chrooted environment in the
right dir.
it breaks the purpose
why? they will be accessable from both outside as inside the chroot,
whether you create them from the chroot or not.
-Otto
Re: standard FAQ procedure ... in chroot
On Sat, Jun 7, 2014 at 12:14 PM, sven falempin sven.falem...@gmail.com wrote:
On Sat, Jun 7, 2014 at 11:30 AM, Otto Moerbeek o...@drijf.net wrote:
On Sat, Jun 07, 2014 at 08:20:00AM -0400, sven falempin wrote:
On Sat, Jun 7, 2014 at 6:58 AM, Stuart Henderson s...@spacehopper.org
wrote:
On 2014-06-06, sven falempin sven.falem...@gmail.com wrote:
Dear misc readers,
I try to understand why MAKEDEV is failing inside my chroot, while i
can manually create some dev with mknod .
Like:
SCRIPT ${DESTDIR}/dev/MAKEDEV dev/MAKEDEV
SPECIAL cd dev; sh MAKEDEV ramdisk
sh: stdin[1]: mknod: console: Invalid argument
sh: stdin[1]: mknod: tty: Invalid argument
AFAIK everything else is ok inside the CHROOT.
Help is welcome.
Your chroot is probably on a filesystem mounted with nodev.
nop , this mistake i did and already corrected. I can call a pipe |
or read /dev/(u)random etc... (i called MAKEDEV outside the chroot and
then enter it), but when inside...i have those Invalid argument.
i suspect a config file somewhere but i am in the dark.
Use set -x in the MAKEDV script to see what command fails.
i try right away , thanks
Or just create the device nodes from a non-chrooted environment in the
right dir.
it breaks the purpose
# ksh -x MAKEDEV all
+ PATH=/sbin:/usr/sbin:/bin:/usr/bin
+ T=MAKEDEV
[ ... ]
+ echo chgrp operator vnd0a [ ... ] enrst1
sh: stdin[1]: mknod: drm0: Invalid argument
even darker, why calling chgrp and then having a mknod error, set +x
inside the script ?
Re: standard FAQ procedure ... in chroot
On Sat, Jun 07, 2014 at 12:28:28PM -0400, sven falempin wrote:
On Sat, Jun 7, 2014 at 12:14 PM, sven falempin sven.falem...@gmail.com
wrote:
On Sat, Jun 7, 2014 at 11:30 AM, Otto Moerbeek o...@drijf.net wrote:
On Sat, Jun 07, 2014 at 08:20:00AM -0400, sven falempin wrote:
On Sat, Jun 7, 2014 at 6:58 AM, Stuart Henderson s...@spacehopper.org
wrote:
On 2014-06-06, sven falempin sven.falem...@gmail.com wrote:
Dear misc readers,
I try to understand why MAKEDEV is failing inside my chroot, while i
can manually create some dev with mknod .
Like:
SCRIPT ${DESTDIR}/dev/MAKEDEV dev/MAKEDEV
SPECIAL cd dev; sh MAKEDEV ramdisk
sh: stdin[1]: mknod: console: Invalid argument
sh: stdin[1]: mknod: tty: Invalid argument
AFAIK everything else is ok inside the CHROOT.
Help is welcome.
Your chroot is probably on a filesystem mounted with nodev.
nop , this mistake i did and already corrected. I can call a pipe |
or read /dev/(u)random etc... (i called MAKEDEV outside the chroot and
then enter it), but when inside...i have those Invalid argument.
i suspect a config file somewhere but i am in the dark.
Use set -x in the MAKEDV script to see what command fails.
i try right away , thanks
Or just create the device nodes from a non-chrooted environment in the
right dir.
it breaks the purpose
# ksh -x MAKEDEV all
+ PATH=/sbin:/usr/sbin:/bin:/usr/bin
+ T=MAKEDEV
[ ... ]
+ echo chgrp operator vnd0a [ ... ] enrst1
sh: stdin[1]: mknod: drm0: Invalid argument
even darker, why calling chgrp and then having a mknod error, set +x
inside the script ?
you can put set -x inside functions the trace them
-Otto
Re: standard FAQ procedure ... in chroot
On Sat, Jun 7, 2014 at 12:38 PM, Otto Moerbeek o...@drijf.net wrote:
On Sat, Jun 07, 2014 at 12:28:28PM -0400, sven falempin wrote:
On Sat, Jun 7, 2014 at 12:14 PM, sven falempin sven.falem...@gmail.com
wrote:
On Sat, Jun 7, 2014 at 11:30 AM, Otto Moerbeek o...@drijf.net wrote:
On Sat, Jun 07, 2014 at 08:20:00AM -0400, sven falempin wrote:
On Sat, Jun 7, 2014 at 6:58 AM, Stuart Henderson s...@spacehopper.org
wrote:
On 2014-06-06, sven falempin sven.falem...@gmail.com wrote:
Dear misc readers,
I try to understand why MAKEDEV is failing inside my chroot, while i
can manually create some dev with mknod .
Like:
SCRIPT ${DESTDIR}/dev/MAKEDEV dev/MAKEDEV
SPECIAL cd dev; sh MAKEDEV ramdisk
sh: stdin[1]: mknod: console: Invalid argument
sh: stdin[1]: mknod: tty: Invalid argument
AFAIK everything else is ok inside the CHROOT.
Help is welcome.
Your chroot is probably on a filesystem mounted with nodev.
nop , this mistake i did and already corrected. I can call a pipe |
or read /dev/(u)random etc... (i called MAKEDEV outside the chroot and
then enter it), but when inside...i have those Invalid argument.
i suspect a config file somewhere but i am in the dark.
Use set -x in the MAKEDV script to see what command fails.
i try right away , thanks
Or just create the device nodes from a non-chrooted environment in the
right dir.
it breaks the purpose
# ksh -x MAKEDEV all
+ PATH=/sbin:/usr/sbin:/bin:/usr/bin
+ T=MAKEDEV
[ ... ]
+ echo chgrp operator vnd0a [ ... ] enrst1
sh: stdin[1]: mknod: drm0: Invalid argument
even darker, why calling chgrp and then having a mknod error, set +x
inside the script ?
you can put set -x inside functions the trace them
oh!, there is some echo | sh at the end..
-Otto
well, even manually i have trouble:
# cd /root
# mknod stdin c 22 0
# rm stdin
# chroot /mirror/altroot/
# mount | cat
/dev/sd0a on / type ffs (local)
/dev/sd0k on /mirror type ffs (local)
[...]
# cd /lol
# mknod stdin c 22 0
/bin/ksh: mknod: stdin: Invalid argument
# uname -a
OpenBSD sources.citypassenger.com 5.5 GENERIC#271 amd64
Is this some kind of security protection ?
--
-
() ascii ribbon campaign - against html e-mail
/\
Re: standard FAQ procedure ... in chroot
On Sat, Jun 07, 2014 at 01:30:01PM -0400, sven falempin wrote:
On Sat, Jun 7, 2014 at 12:38 PM, Otto Moerbeek o...@drijf.net wrote:
On Sat, Jun 07, 2014 at 12:28:28PM -0400, sven falempin wrote:
On Sat, Jun 7, 2014 at 12:14 PM, sven falempin sven.falem...@gmail.com
wrote:
On Sat, Jun 7, 2014 at 11:30 AM, Otto Moerbeek o...@drijf.net wrote:
On Sat, Jun 07, 2014 at 08:20:00AM -0400, sven falempin wrote:
On Sat, Jun 7, 2014 at 6:58 AM, Stuart Henderson
s...@spacehopper.org wrote:
On 2014-06-06, sven falempin sven.falem...@gmail.com wrote:
Dear misc readers,
I try to understand why MAKEDEV is failing inside my chroot, while i
can manually create some dev with mknod .
Like:
SCRIPT ${DESTDIR}/dev/MAKEDEV dev/MAKEDEV
SPECIAL cd dev; sh MAKEDEV ramdisk
sh: stdin[1]: mknod: console: Invalid argument
sh: stdin[1]: mknod: tty: Invalid argument
AFAIK everything else is ok inside the CHROOT.
Help is welcome.
Your chroot is probably on a filesystem mounted with nodev.
nop , this mistake i did and already corrected. I can call a pipe |
or read /dev/(u)random etc... (i called MAKEDEV outside the chroot and
then enter it), but when inside...i have those Invalid argument.
i suspect a config file somewhere but i am in the dark.
Use set -x in the MAKEDV script to see what command fails.
i try right away , thanks
Or just create the device nodes from a non-chrooted environment in the
right dir.
it breaks the purpose
# ksh -x MAKEDEV all
+ PATH=/sbin:/usr/sbin:/bin:/usr/bin
+ T=MAKEDEV
[ ... ]
+ echo chgrp operator vnd0a [ ... ] enrst1
sh: stdin[1]: mknod: drm0: Invalid argument
even darker, why calling chgrp and then having a mknod error, set +x
inside the script ?
you can put set -x inside functions the trace them
oh!, there is some echo | sh at the end..
-Otto
well, even manually i have trouble:
# cd /root
# mknod stdin c 22 0
# rm stdin
# chroot /mirror/altroot/
# mount | cat
/dev/sd0a on / type ffs (local)
/dev/sd0k on /mirror type ffs (local)
[...]
# cd /lol
# mknod stdin c 22 0
/bin/ksh: mknod: stdin: Invalid argument
# uname -a
OpenBSD sources.citypassenger.com 5.5 GENERIC#271 amd64
Is this some kind of security protection ?
of course... see mknod(2).
Re: new OpenSSL flaws
previously on this list Giancarlo Razzolini contributed: What gives LibreSSL more credibility? There's almost nothing new or innovative in it; it's just a cleaned up copy of OpenSSL. You should do your homework. Too right, also those previous two lines showed he has no clue about real security and what has proven to work and what has proven exploitable in the past. It's just cleaner so why is it more credible?? Also OpenBSD is focussing on what actually matters and are unrestricted in that aim and so I see LibreSSl leaving OpenSSL in the dust and would use that for my companies products out of the two. Emergency updating is unneeded expense especially if an UNUSED feature is to blame. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___
Re: standard FAQ procedure ... in chroot
On Sat, Jun 7, 2014 at 1:41 PM, Otto Moerbeek o...@drijf.net wrote:
On Sat, Jun 07, 2014 at 01:30:01PM -0400, sven falempin wrote:
On Sat, Jun 7, 2014 at 12:38 PM, Otto Moerbeek o...@drijf.net wrote:
On Sat, Jun 07, 2014 at 12:28:28PM -0400, sven falempin wrote:
On Sat, Jun 7, 2014 at 12:14 PM, sven falempin sven.falem...@gmail.com
wrote:
On Sat, Jun 7, 2014 at 11:30 AM, Otto Moerbeek o...@drijf.net wrote:
On Sat, Jun 07, 2014 at 08:20:00AM -0400, sven falempin wrote:
On Sat, Jun 7, 2014 at 6:58 AM, Stuart Henderson
s...@spacehopper.org wrote:
On 2014-06-06, sven falempin sven.falem...@gmail.com wrote:
Dear misc readers,
I try to understand why MAKEDEV is failing inside my chroot, while
i
can manually create some dev with mknod .
Like:
SCRIPT ${DESTDIR}/dev/MAKEDEV dev/MAKEDEV
SPECIAL cd dev; sh MAKEDEV ramdisk
sh: stdin[1]: mknod: console: Invalid argument
sh: stdin[1]: mknod: tty: Invalid argument
AFAIK everything else is ok inside the CHROOT.
Help is welcome.
Your chroot is probably on a filesystem mounted with nodev.
nop , this mistake i did and already corrected. I can call a pipe |
or read /dev/(u)random etc... (i called MAKEDEV outside the chroot and
then enter it), but when inside...i have those Invalid argument.
i suspect a config file somewhere but i am in the dark.
Use set -x in the MAKEDV script to see what command fails.
i try right away , thanks
Or just create the device nodes from a non-chrooted environment in the
right dir.
it breaks the purpose
# ksh -x MAKEDEV all
+ PATH=/sbin:/usr/sbin:/bin:/usr/bin
+ T=MAKEDEV
[ ... ]
+ echo chgrp operator vnd0a [ ... ] enrst1
sh: stdin[1]: mknod: drm0: Invalid argument
even darker, why calling chgrp and then having a mknod error, set +x
inside the script ?
you can put set -x inside functions the trace them
oh!, there is some echo | sh at the end..
-Otto
well, even manually i have trouble:
# cd /root
# mknod stdin c 22 0
# rm stdin
# chroot /mirror/altroot/
# mount | cat
/dev/sd0a on / type ffs (local)
/dev/sd0k on /mirror type ffs (local)
[...]
# cd /lol
# mknod stdin c 22 0
/bin/ksh: mknod: stdin: Invalid argument
# uname -a
OpenBSD sources.citypassenger.com 5.5 GENERIC#271 amd64
Is this some kind of security protection ?
of course... see mknod(2).
i read it and still does not understand.
--
-
() ascii ribbon campaign - against html e-mail
/\
OpenBSD 5.5 on mSATA SSD unit in PC Engines APU.1C - bad dir ino 2 at offset 0: mangled entry kernel panic
I'm having troubles installing OpenBSD 5.5 (amd64) on a mSATA SSD card (
http://pcengines.ch/msata16a.htm) PC Engines APU.1C device (
http://pcengines.ch/apu.htm) with the most recent BIOS version.
I've made several attempts, using install55.fs copied to an SD card, with
both 5.5-release and 5.5-current (June 6th snapshot).
Most attempts have failed, either during the install (filesystem creation
phase or during the sets extraction phase) or during the first boot after
the initial install (case reported in this message).
I wonder if I have a faulty SSD unit.
In any case, here's my dmesg:
ddb{1} dmesg
OpenBSD 5.5 (GENERIC.MP) #315: Wed Mar 5 09:37:46 MST 2014
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4245995520 (4049MB)
avail mem = 4124356608 (3933MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdf16d820 (6 entries)
bios0: vendor coreboot version SageBios_PCEngines_APU-45 date 04/05/2014
bios0: PC Engines APU
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP SPCR HPET APIC HEST SSDT SSDT SSDT
acpi0: wakeup devices AGPB(S4) HDMI(S4) PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4)
PE2
0(S4) PE21(S4) PE22(S4) PE23(S4) PIBR(S4) UOH1(S3) UOH2(S3) UOH3(S3)
UOH4(S3) U
OH5(S3) [...]
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpihpet0 at acpi0: 14318180 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD G-T40E Processor, 1000.14 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,C
FLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,LA
HF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC
cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB
64b/line 1
6-way L2 cache
cpu0: 8 4MB entries fully associative
cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 200MHz
cpu0: mwait min=64, max=64, C-substates=0.0.0.0.0, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD G-T40E Processor, 1000.00 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,C
FLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,LA
HF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC
cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB
64b/line 1
6-way L2 cache
cpu1: 8 4MB entries fully associative
cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 21, 24 pins
acpiprt0 at acpi0: bus -1 (AGPB)
acpiprt1 at acpi0: bus -1 (HDMI)
acpiprt2 at acpi0: bus 1 (PBR4)
acpiprt3 at acpi0: bus 2 (PBR5)
acpiprt4 at acpi0: bus 3 (PBR6)
acpiprt5 at acpi0: bus -1 (PBR7)
acpiprt6 at acpi0: bus 5 (PE20)
acpiprt7 at acpi0: bus -1 (PE21)
acpiprt8 at acpi0: bus -1 (PE22)
acpiprt9 at acpi0: bus -1 (PE23)
acpiprt10 at acpi0: bus 0 (PCI0)
acpiprt11 at acpi0: bus 4 (PIBR)
acpicpu0 at acpi0: C2, PSS
acpicpu1 at acpi0: C2, PSS
acpibtn0 at acpi0: PWRB
cpu0: 1000 MHz: speeds: 1000 800 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 AMD AMD64 14h Host rev 0x00
ppb0 at pci0 dev 4 function 0 AMD AMD64 14h PCIE rev 0x00: msi
pci1 at ppb0 bus 1
re0 at pci1 dev 0 function 0 Realtek 8168 rev 0x06: RTL8168E/8111E
(0x2c00), m
si, address 00:0d:b9:33:98:cc
rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 4
ppb1 at pci0 dev 5 function 0 AMD AMD64 14h PCIE rev 0x00: msi
pci2 at ppb1 bus 2
re1 at pci2 dev 0 function 0 Realtek 8168 rev 0x06: RTL8168E/8111E
(0x2c00), m
si, address 00:0d:b9:33:98:cd
rgephy1 at re1 phy 7: RTL8169S/8110S PHY, rev. 4
ppb2 at pci0 dev 6 function 0 AMD AMD64 14h PCIE rev 0x00: msi
pci3 at ppb2 bus 3
re2 at pci3 dev 0 function 0 Realtek 8168 rev 0x06: RTL8168E/8111E
(0x2c00), m
si, address 00:0d:b9:33:98:ce
rgephy2 at re2 phy 7: RTL8169S/8110S PHY, rev. 4
ahci0 at pci0 dev 17 function 0 ATI SBx00 SATA rev 0x40: apic 2 int 19,
AHCI 1
.2
scsibus0 at ahci0: 32 targets
sd0 at scsibus0 targ 0 lun 0: ATA, SuperSSpeed mSAT, V462 SCSI3 0/direct
fixe
d t10.ATA_SuperSSpeed_mSATA_SSD_16GB_YTAF1405A_
sd0: 15258MB, 512 bytes/sector, 31248704 sectors
ohci0 at pci0 dev 18 function 0 ATI SB700 USB rev 0x00: apic 2 int 18,
versio
n 1.0, legacy support
ehci0 at pci0 dev 18 function 2 ATI SB700 USB2 rev 0x00: apic 2 int 17
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 ATI EHCI root hub rev 2.00/1.00 addr 1
ohci1 at pci0 dev 19 function 0 ATI SB700 USB rev 0x00: apic 2 int 18,
versio
n 1.0, legacy support
ehci1 at pci0 dev 19 function 2 ATI SB700 USB2 rev 0x00: apic 2 int 17
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 ATI EHCI root hub rev 2.0ev 20 function 0 ATI SBx00 SMBus
rev 0x42: polling
iic0 at piixpm0
pcib0 at pci0 dev 20
Re: standard FAQ procedure ... in chroot
Is this some kind of security protection ? of course... see mknod(2). i read it and still does not understand. Check the description of EINVAL.
Re: OpenBSD 5.5 on mSATA SSD unit in PC Engines APU.1C - bad dir ino 2 at offset 0: mangled entry kernel panic
On 2014-06-07 12:51, JB M wrote: I'm having troubles installing OpenBSD 5.5 (amd64) on a mSATA SSD card ( http://pcengines.ch/msata16a.htm) PC Engines APU.1C device ( http://pcengines.ch/apu.htm) with the most recent BIOS version. I've made several attempts, using install55.fs copied to an SD card, with both 5.5-release and 5.5-current (June 6th snapshot). Most attempts have failed, either during the install (filesystem creation phase or during the sets extraction phase) or during the first boot after the initial install (case reported in this message). I wonder if I have a faulty SSD unit. Does the mSATA drive have the new firmware, or is it one of the problem drives from earlier? If you have a null modem serial cable handy, you could try PXE booting and then installing the OS to the SD Card instead of the mSATA drive to at least rule out any other issues. Then try the same process and install to the mSATA card and see if you have the same problem again. Mike
Re: standard FAQ procedure ... in chroot
On Sat, Jun 7, 2014 at 3:12 PM, Miod Vallat m...@online.fr wrote: Is this some kind of security protection ? of course... see mknod(2). i read it and still does not understand. Check the description of EINVAL. i was reading the (8) man pages :-( So DESTDIR is nor working and make release is calling MAKEDEV, so there s no way to make a release without changing the system that build it. That is odd. Should i try to fix DESTDIR, or change the release process to skip MAKEDEV (i guess it is made to build the ramdisk ?) -- - () ascii ribbon campaign - against html e-mail /\
Thank you thank you thank you
# dmesg console is /virtual-devices@100/console@1 Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2014 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 5.5 (GENERIC.MP) #173: Tue Mar 4 14:47:47 MST 2014 dera...@sparc64.openbsd.org:/usr/src/sys/arch/sparc64/compile/GENERIC.MP real mem = 17045651456 (16256MB) avail mem = 16759693312 (15983MB) mainbus0 at root: SPARC Enterprise T5220 cpu0 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1165.379 MHz cpu1 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1165.379 MHz cpu2 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1165.379 MHz cpu3 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1165.379 MHz cpu4 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1165.379 MHz cpu5 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1165.379 MHz cpu6 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1165.379 MHz cpu7 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1165.379 MHz cpu8 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1165.379 MHz cpu9 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1165.379 MHz cpu10 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1165.379 MHz cpu11 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1165.379 MHz cpu12 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1165.379 MHz cpu13 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1165.379 MHz cpu14 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1165.379 MHz cpu15 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1165.379 MHz cpu16 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1165.379 MHz cpu17 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1165.379 MHz cpu18 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1165.379 MHz cpu19 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1165.379 MHz cpu20 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1165.379 MHz cpu21 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1165.379 MHz cpu22 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1165.379 MHz cpu23 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1165.379 MHz cpu24 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1165.379 MHz cpu25 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1165.379 MHz cpu26 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1165.379 MHz cpu27 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1165.379 MHz cpu28 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1165.379 MHz cpu29 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1165.379 MHz cpu30 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1165.379 MHz cpu31 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1165.379 MHz
Re: new OpenSSL flaws
On 2014-06-07, Maxime Villard m...@m00nbsd.net wrote: What gives LibreSSL more credibility? There's almost nothing new or innovative in it; it's just a cleaned up copy of OpenSSL. There might be some changes in the future, but you can be sure that LibreSSL will lag behind OpenSSL - and most of the code will remain the same. We'll just have to wait and see about the future, it's too early to make guesses. One thing's for sure though, new and innovative is *not* what is needed here at this point. Much of what's needed is tedious slog: removing unnecessary/dangerous pieces, finding our way around the code and commit history, discovering what areas might be harbouring lurking horrors. Look at some of the major changes that have been made to improve security in libressl so far, there are things like stopping feeding information from *private keys* to the (pluggable!) RNG subsystem and getting rid of the buf freelists (btw on that note, I found it interesting that the openssl commits refering to bugs that we ran into after removing the buf freelists are only talking about SSL_MODE_RELEASE_BUFFERS). New and innovative, definitely not, but no worse for it. Contributing code upstream would have been a way more productive approach; it would have given a better image of the OpenBSD team, more credibility, and people would have been tempted to look deeper at what those guys do, to then figure out that these things are potentially good products. I would hope that some openssl people keep track of commits/fixes in libressl, just as some people here are keeping track of commits to openssl. I'm sure other less public-spirited people are keeping an eye on both plus doing plenty of their own research. Bugs that are found in libressl would largely *not* be found with the legacy code still in place and original indentation style; I think I speak for most OpenBSD people (and probably many others who have looked at this codebase) when I say it's distracting to the point of frustration. Too many why on earth is it written like this moments to be able to concentrate on the code itself.
Re: OpenBSD 5.5 on mSATA SSD unit in PC Engines APU.1C - bad dir ino 2 at offset 0: mangled entry kernel panic
On Sat, Jun 7, 2014 at 8:51 PM, JB M jbm.li...@gmail.com wrote: I'm having troubles installing OpenBSD 5.5 (amd64) on a mSATA SSD card ( http://pcengines.ch/msata16a.htm) PC Engines APU.1C device ( http://pcengines.ch/apu.htm) with the most recent BIOS version. I've made several attempts, using install55.fs copied to an SD card, with both 5.5-release and 5.5-current (June 6th snapshot). Most attempts have failed, either during the install (filesystem creation phase or during the sets extraction phase) or during the first boot after the initial install (case reported in this message). Same thing for me with : sd0 at scsibus1 targ 0 lun 0: ATA, SuperSSpeed mSAT, V462 SCSI3 0/direct fixed t10.ATA_SuperSSpeed_mSATA_SSD_16GB_YTAF140500376_ sd0: 15258MB, 512 bytes/sector, 31248704 sectors Installing on a USB drive solved the problem.
Re: standard FAQ procedure ... in chroot
The description of EINVAL in mknod(2) is wrong:
[EINVAL] The process is running within an alternate root
directory, as created by chroot(2).
Even if a process chroot()s back to /, it can't create a device node.
The program below exits with EINVAL:
#include sys/stat.h
#include unistd.h
int main() {
chroot(/);
if (mknod(/t, 0x21b6, 0x1600) == -1) /* stdin amd64 */
err(1, mknod);
}
On Sat, Jun 7, 2014 at 2:42 PM, Miod Vallat m...@online.fr wrote:
Is this some kind of security protection ?
of course... see mknod(2).
i read it and still does not understand.
Check the description of EINVAL.
