Re: autopledge
On 2 Jun 2023, at 20:35, William Ahern wrote: On Fri, Jun 02, 2023 at 04:24:31PM +0100, Leah Rowe wrote: Hi everyone, I had an interesting idea for OpenBSD. Haven't tried it yet. I'm wondering what other people think of it? The idea is, thus: 1) Do execution tracing and just run a program. Do everything possible in it to the fullest extent feasible and get an entire log of the trace. OpenBSD can do tracing: 2) Write a program that scans for all system calls in the trace, suggesting what pledge promises to use. See: https://man.openbsd.org/pledge.2 I call this idea "autopledge". OpenBSD once had a tool like this as part of its systrace sandboxing facility, in the form of the -A option argument: -AAutomatically generate a policy that allows every operation the application executes. The created policy functions as a base that can be refined. See https://man.openbsd.org/OpenBSD-5.9/systrace.1#A OpenBSD has already been down this road. It turned out that not only was the notion, "if we just made it easier to autogenerate a sandbox configuration, more people would use it", wrong--more people did not--it was based on faulty premises. This real-world experience is what led to pledge and unveil, and why you'll find little interest in a tool predicated on reducing the need for a piece of software to be thoughtfully and deliberately refactored. Rather, the point of pledge and unveil is to make that deliberate refactoring as pleasant and minimal as is practicable. This is an excellent, well-stated and helpful answer. Thanks. -- devin learn more about me & support my work: https://www.patreon.com/trianglemutualaid
Re: Removing PF
Will authpf be around?
Re: Inflamation by Bryan Cantrill Content-Transfer-Encoding: 8bit
Thanks. On 13 Jun 2018, at 23:48, Theo de Raadt wrote: > In some forums, Bryan Cantrill is crafting a fiction. > > He is saying the FPU problem (and other problems) were received > as a leak. > > He is not being truthful, inventing a storyline, and has not asked me > for the facts. > > This was discovered by guessing Intel made a mistake. > > We are doing the best for OpenBSD. Our commit is best effort for our > user community when Intel didn't reply to mails asking for us to be > included. But we were not included, there was no reply. End of story. > That leaves us to figure things out ourselves. > > Bryan is just upset we guessed right. It is called science.
Re: faq/current.html: Mention sudo removal
On 4 Jul 2015, at 11:16, Todd C. Miller wrote: On Sat, 04 Jul 2015 15:36:58 +0530, Hrishikesh Muruk wrote: Why is sudo being removed from base? It is pretty useful. I imagine many use sudo The version of sudo in base was 5 years old and not really maintainable. Theo has been uncomfortable with the amount of code in sudo that runs as root so there was resistance to updating it to a newer version. Moving sudo to ports means we have a more modern version available and also makes it possible to have an LDAP flavor. Sudo in base will likely be replaced either by tedu's doas or an extended su. - todd Sounds reasonable. Is there a place to read up on "does" or is that in very early stages yet? devin -- contact info: http://nacredata.com/devin Ask me about Google Apps for Work: hosting your domain-branded email, calendar and cloud storage on Google's infrastructure.
Re: Want to help upstream software improve their random?
On 12 Dec 2014, at 5:43, Theo de Raadt wrote: >> On 12 Dec 2014, at 5:02, Theo de Raadt wrote: >> >>> In all of these code blocks are a well-known piece of information >>> (same time on your machine as everywhere else) is being used to seed a >>> deterministic number generator. >>> >>> At some later point, deterministic numbers are taken out using rand(), >>> random(), drand48(), lrand48(), mrand48(), or srand48(), or some >>> derivative function inside the program itself, and used for WHO KNOWS >>> WHAT PURPOSE. >>> >>> I did not audit what the numbers are being used for. >>> >>> Quite likely some numbers are just used to help hashing. Some could >>> be used to print pretty pictures. But in xulrunner? In the zip >>> password >>> creator? In postgresql, or say in openldap (a network related thing)? >>> >>> It is doubtful they are all fine. >>> >>> For the benefit of other projects who haven't taken the same steps as >>> OpenBSD, it would be nice if some people helped out these pieces of >>> software. >>> >>> EMBOSS-6.0.1srand((unsigned) time(&tm)); >> [...] >> >> What you say makes sense. Is there a best practice alternative you >> suggest or did I miss that? Perhaps just some better initiation value, >> preferably not all from the same place? > > These code sequences do not need deterministic values. They actually > want non-deterministic values. Steps are like this: > >1. Remove the srand(), srandom(), srand48(), seed48(), > lcong48() calls. > >2. Replace all rand(), random(), lrand48(), mrand48() calls with > arc4random() > >3. If the calls use %, consider using arcrandom_uniform() instead. > >4. If it loops to fill a buffer, use arc4random_buf() > >5. Replace drand48() with arc4random and some floating point, but > be careful. drand48() is very rare. > > Now, talk to the upstream projects. They will reject your changes > because Linux lacks arc4random(). > > Basically, only Linux and Solaris lack arc4random(). All the other > platforms have it. > > There are libraries available which provide arc4random() on Linux, so > maybe you find an upstream software provider who is willing to create > a dependency on such a library on Linux. > > Lots of software is doing precisely that, so don't be afraid. Got it. Thanks. devin -- contact info: http://nacredata.com/devin gpg public key: http://www.nacredata.com/public_key.txt Use unique, strong passwords! https://www.nacredata.com/password.php
Re: Want to help upstream software improve their random?
On 12 Dec 2014, at 5:02, Theo de Raadt wrote: In all of these code blocks are a well-known piece of information (same time on your machine as everywhere else) is being used to seed a deterministic number generator. At some later point, deterministic numbers are taken out using rand(), random(), drand48(), lrand48(), mrand48(), or srand48(), or some derivative function inside the program itself, and used for WHO KNOWS WHAT PURPOSE. I did not audit what the numbers are being used for. Quite likely some numbers are just used to help hashing. Some could be used to print pretty pictures. But in xulrunner? In the zip password creator? In postgresql, or say in openldap (a network related thing)? It is doubtful they are all fine. For the benefit of other projects who haven't taken the same steps as OpenBSD, it would be nice if some people helped out these pieces of software. EMBOSS-6.0.1srand((unsigned) time(&tm)); [...] What you say makes sense. Is there a best practice alternative you suggest or did I miss that? Perhaps just some better initiation value, preferably not all from the same place? devin -- contact info: http://nacredata.com/devin gpg public key: http://www.nacredata.com/public_key.txt Use unique, strong passwords! https://www.nacredata.com/password.php
Re: LibreSSL: GOST ciphers implementation
On 5 Nov 2014, at 20:25, Theo de Raadt wrote: How do we find people on the internet who care, and knit them into a community, and then somewhere down the road meet them and have them become this so-called 'core developer' group? We start reading code from them. The code, yes, the code. Nothing to stop anyone from being suspicious for any reason whatsoever and giving some code some extra review. So much the better. devin -- contact info: http://nacredata.com/devin gpg public key: http://www.nacredata.com/public_key.txt Use unique, strong passwords! https://www.nacredata.com/password.php
Re: missing ports.tar.gz in snapshot
On Mar 6, 2014, at 3:34 PM, Theo de Raadt wrote: >>> Are all the ports in the packages in snapshots? > > The best way to get source code from our project is not in tar files, > but using the repository-access methods described on the web site > and in the FAQ. Then it is easier to move your tree forward in time, > rather than downloading files this big, every time. > > -rw-r--r-- 1 deraadt wheel 21.8M Mar 5 13:14 ports.tar.gz > -rw-r--r-- 1 deraadt wheel 160M Mar 5 09:46 src.tar.gz > -rw-r--r-- 1 deraadt wheel 110M Mar 5 09:46 xenocara.tar.gz > OK, sure, cvs update the ports tree. That works for me. Now that I think about it, I'm sure that's what I've done at least some of the time. No problem.
Re: missing ports.tar.gz in snapshot
On Mar 6, 2014, at 3:13 PM, Vijay Sankar wrote: > Quoting Theo de Raadt : > >>> is there a reason, why there is no ports.tar.gz in the latest snapshot >>> folder? >> >> At present, it is not being built in the ftp area any more. >> >> I'd like to ask. Does anyone find it useful? It is not in sync with the >> packages beside it. >> >> > Are all the ports in the packages in snapshots? I seem to remember needing to build some of the things I use to test, but maybe that has changed. I use snapshots when I have time to test, so whatever direction you want to give as far as testing goes, just let us know. devin
Re: base apache and HonorCipherOrder
Thanks all; I am glad to see this.
On Thu, Jul 11, 2013 at 11:35 AM, Joel Sing wrote:
> On Mon, 8 Jul 2013, Damien Miller wrote:
> > On Sun, 7 Jul 2013, Aaron Stellman wrote:
> > > On Tue, Apr 23, 2013 at 09:08:19AM +0200, Otto Moerbeek wrote:
> > > > If there is any interest, I might add the manual stuff, get ok's and
> > > > commit it.
> > >
> > > I find it useful to have SSLHonorCipherOrder in OpenBSD's apache.
> >
> > More than that, AFAIK it is necessary to mitigate some of the TLS crypto
> > attacks. IMO it is well worth having.
> >
> > It would also be good if someone could make a patch to enable ECDHE
> cipher
> > suites in Apache-1.x.
> > This nginx patch is a good reference to what needs to
> > be done:
> >
> > http://hg.nginx.org/nginx/rev/0832a6997227
>
> The following should do the trick...
>
> $ openssl s_client -connect localhost:443 2>&1 is"
> New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
>
> Index: conf/httpd.conf
> ===
> RCS file: /cvs/src/usr.sbin/httpd/conf/httpd.conf,v
> retrieving revision 1.26
> diff -u -p -u -p -r1.26 httpd.conf
> --- conf/httpd.conf 3 Jun 2009 18:28:21 - 1.26
> +++ conf/httpd.conf 11 Jul 2013 15:28:21 -
> @@ -1034,6 +1034,11 @@ SSLEngine on
> # List the ciphers that the client is permitted to negotiate.
> # See the mod_ssl documentation for a complete list.
> #SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP
> +
> +# SSL ECDH Curve:
> +# Named curve to use when generating ephemeral EC keys for an
> +# ECDHE-based cipher suite.
> +#SSLECDHCurve prime256v1
>
> # Server Certificate:
> # Point SSLCertificateFile at a PEM encoded certificate. If
> Index: conf/httpd.conf-dist
> ===
> RCS file: /cvs/src/usr.sbin/httpd/conf/httpd.conf-dist,v
> retrieving revision 1.20
> diff -u -p -u -p -r1.20 httpd.conf-dist
> --- conf/httpd.conf-dist1 Apr 2009 06:47:34 - 1.20
> +++ conf/httpd.conf-dist11 Jul 2013 15:28:21 -
> @@ -1045,6 +1045,11 @@ SSLEngine on
> # See the mod_ssl documentation for a complete list.
> SSLCipherSuite
> ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
>
> +# SSL ECDH Curve:
> +# Named curve to use when generating ephemeral EC keys for an
> +# ECDHE-based cipher suite.
> +SSLECDHCurve prime256v1
> +
> # Server Certificate:
> # Point SSLCertificateFile at a PEM encoded certificate. If
> # the certificate is encrypted, then you will be prompted for a
> Index: src/modules/ssl/mod_ssl.c
> ===
> RCS file: /cvs/src/usr.sbin/httpd/src/modules/ssl/mod_ssl.c,v
> retrieving revision 1.11
> diff -u -p -u -p -r1.11 mod_ssl.c
> --- src/modules/ssl/mod_ssl.c 11 Jul 2013 12:41:52 - 1.11
> +++ src/modules/ssl/mod_ssl.c 11 Jul 2013 15:28:21 -
> @@ -113,6 +113,9 @@ static command_rec ssl_config_cmds[] = {
> AP_ALL_CMD(CipherSuite, TAKE1,
> "Colon-delimited list of permitted SSL Ciphers "
> "(`XXX:...:XXX' - see manual)")
> +AP_SRV_CMD(ECDHCurve, TAKE1,
> + "Name of ECDH curve to use for ephemeral EC keys "
> + "(`curve' - see manual)")
> AP_SRV_CMD(CertificateFile, TAKE1,
> "SSL Server Certificate file "
> "(`/path/to/file' - PEM or DER encoded)")
> Index: src/modules/ssl/mod_ssl.h
> ===
> RCS file: /cvs/src/usr.sbin/httpd/src/modules/ssl/mod_ssl.h,v
> retrieving revision 1.22
> diff -u -p -u -p -r1.22 mod_ssl.h
> --- src/modules/ssl/mod_ssl.h 11 Jul 2013 12:41:52 - 1.22
> +++ src/modules/ssl/mod_ssl.h 11 Jul 2013 15:28:22 -
> @@ -514,6 +514,7 @@ typedef struct {
> char*szCACertificateFile;
> char*szLogFile;
> char*szCipherSuite;
> +char*szECDHCurve;
> FILE*fileLogFile;
> int nLogLevel;
> BOOL cipher_server_pref;
> @@ -592,6 +593,7 @@ const char *ssl_cmd_SSLRandomSeed(cmd_p
> const char *ssl_cmd_SSLEngine(cmd_parms *, char *, int);
> const char *ssl_cmd_SSLHonorCipherOrder(cmd_parms *, char *, int);
> const char *ssl_cmd_SSLCipherSuite(cmd_parms *, SSLDirConfigRec *, char
> *);
> +const char *ssl_cmd_SSLECDHCurve(cmd_parms *, char *, char *);
> const char *ssl_cmd_SSLCertificateFile(cmd_parms *, char *, char *);
> const char *ssl_cmd_SSLCertificateKeyFile(cmd_parms *, char *, char *);
> const char *ssl_cmd_SSLCertificateChainFile(cmd_parms *, char *, char *);
> Index: src/modules/ssl/ssl_engine_config.c
> ===
> RCS file: /cvs/src/usr.sbin/httpd/src/modules/ssl/ssl_engine_config.c,v
> retrieving revision 1.20
> diff -u -p -u -p -r1.20 ssl_engine_config.c
> --- src/modules/ssl/ssl_engine_c
Re: [miniroot/install.sub] skip x* sets if do not expect to run X.
There are cases where you want to compile some port not directly related to X
but the dependency is missing if you didn't load the X sets. I don't remember
the particular, but I know this has happened to me.
devin
On Jan 12, 2013, at 9:33 PM, Bob Beck wrote:
> No, I normally install all the X sets, I just do not run X on the console.
> So I don't like this.
>
> On Wed, Jan 9, 2013 at 3:43 PM, Gleydson Soares wrote:
>
>> the diff below changes src/distrib/miniroot/install.sub to by default skip
>> x* sets if someone do not expect to run X
>> "Do you expect to run the X Window System [no]"
>>
>> if someone still want to install those sets may select by hand afterwards:
>> "Set name(s)? (or 'abort' or 'done') [done] x*"
>>
>> i've compile a RAMDISK_CD and seems to work fine.
>>
>> ok? feedback?
>> Index: install.sub
>> ===
>> RCS file: /cvs/src/distrib/miniroot/install.sub,v
>> retrieving revision 1.674
>> diff -u -p -r1.674 install.sub
>> --- install.sub 2 Jan 2013 20:35:00 - 1.674
>> +++ install.sub 11 Jan 2013 23:41:45 -
>> @@ -1098,8 +1098,9 @@ install_files() {
>>for _f in $THESETS; do
>>isin $_f $_files || continue;
>>_sets=$(addel $_f $_sets)
>> - if [[ -z $DISPLAY && ! -d /mnt/etc/X11 ]]; then
>> - # No displays and X isn't installed ==> skip X sets
>> + if [[ -z $DISPLAY && ! -d /mnt/etc/X11 || $x11 == n ]];
>> then
>> + # No displays and X isn't installed or do not
>> expect to run X
>> + # => skip X sets
>>isin ${_f%${VERSION}.tgz} xbase xetc xshare xfont
>> xserv && continue
>>fi
>>isin $_f $DEFAULTSETS "site$VERSION-$(hostname -s).tgz" &&
>> \
5.2 SSD won't boot
hp laptop with Intel SSD won't boot under 5.2 - the problem reported on screen appears to be the one described here: http://old.nabble.com/Re%3A-Fwd%3A--mSATA-failure-on-6501-w--OpenBSD-5.0-td32881415.html#a32884546 > ahci0: stopping the port, softreset slot 31 was still active. > ahci0: failed to reset port during timeout handling, disabling it Does anyone have a patch to try or is there a way to boot into the full system starting from a CD or network boot? -- devin
SSD won't be recognized
hp laptop with Intel SSD won't boot under 5.2 - the problem reported on screen appears to be the one described here: http://old.nabble.com/Re%3A-Fwd%3A--mSATA-failure-on-6501-w--OpenBSD-5.0-td32 881415.html#a32884546 > ahci0: stopping the port, softreset slot 31 was still active. > ahci0: failed to reset port during timeout handling, disabling it Does anyone have a patch to try or is there a way to boot into the full system starting from a CD or network boot? -- devin
Re: diff install.sub: if user won't be running X, skip X sets during install
On Dec 31, 2010, at 1:41 PM, Theo de Raadt wrote: Feel free to flame, explain, or generally malign, any logic or unforseen consequences of this diff. Sorry, not going to change this. Before moving to the "always give people X", we had way too many people choose badly and then struggle to install X after the fact. Fair enough, I didn't know the history of this. My own curiositiy, what was the struggle people had? I admit, I might be minimising the difficulty of searching via Google 'openbsd adding sets after install,' or perhaps there is some behind the scenes install bits that I've missed that do not take place when adding the set after-the-fact? 200MB on everyone's disk that they might need, or put up with people who have ADD? We'll put it on everyone's disk... The trouble I've had in the past wasn't so much needing X later, but needing dependencies in the X packages later, FWIW. -- http://nacredata.com/devin
