Re: openssl 3.2.0
Please note that there is a double-free bug in 3.2.0 related to DANE - maybe wait until this is fixed? See the openssl-users mailing list or https://github.com/openssl/openssl/pull/22821
net/isc-bind: configure: WARNING: unrecognized options?
I'm probably doing something wrong, but just in case: these warnings where displayed when I ran make in ports/net/isc-bind/ configure: WARNING: unrecognized options: --enable-filter-, --enable-threads, --with-randomdev, --disable-silent-rules, --disable-gtk-doc Maybe those options are used to build other versions of ISC bind? Below is a trivial patch to remove those options in the list which are in Makefile: Index: Makefile === RCS file: /home/cvs/ports/net/isc-bind/Makefile,v retrieving revision 1.115 diff -u -r1.115 Makefile --- Makefile15 Apr 2020 18:41:07 - 1.115 +++ Makefile19 Apr 2020 09:00:08 - @@ -52,10 +52,7 @@ CONFIGURE_STYLE= autoconf AUTOCONF_VERSION= 2.69 CONFIGURE_ARGS=--enable-full-report \ - --enable-filter- \ - --enable-threads \ --with-libtool \ - --with-randomdev=/dev/random \ --with-libidn2 \ --without-lmdb \ --without-readline \ -- Address is valid for this mailing list only, please do not reply to it direcly, but to the list.
Re: reference pkg-readmes in manual pages
On Fri, Jan 24, 2020, Ingo Schwarze wrote: > Claus Assmann wrote on Fri, Jan 24, 2020 at 09:25:27AM +0100: > > I didn't find a hint about pkg-readmes in the man pages :-( >$ man -k any=pkg-readmes Two mails to the openbsd lists and I learned three new things :-) I only tried man -k pkg-readmes Thanks a lot for the help and the enhancement of the documentation. -- Address is valid for this mailing list only, please do not reply to it direcly, but to the list.
Re: firefox: pledge "", syscall 289
I really appreciate your work of providing upgraded pkgs via -stable; for the user having to change something is a much smaller "problem" than having a pkg with a security problem. Maybe just add a (upgrade) note to the pkg_info output about incompatibilities? Thanks! -- Address is valid for this mailing list only, please do not reply to it direcly, but to the list.
Re: firefox: pledge "", syscall 289
On Thu, Jan 23, 2020, Landry Breuil wrote: > Since 72 was backported to stable pledge config/overrides isnt in > about:config prefs anymore but in /etc/firefox, have a look at the > pkg-readme provided by the package. I didn't find a hint about pkg-readmes in the man pages :-( (I also ran pkg_info to find out more about the firefox port). And since the installation was automated, I also missed the hint when firefox was installed -- my fault, thanks for pointing me to it - that solved the problem. -- Address is valid for this mailing list only, please do not reply to it direcly, but to the list.
firefox: pledge "", syscall 289
Sorry if I missed something, but the last info I found on this
was to set these two options to avoid the problem:
$ fgrep pledge prefs.js
user_pref("security.sandbox.pledge.content", "moo");
user_pref("security.sandbox.pledge.main", "moo");
I also tried to set it to "", but that doesn't help either.
System info:
OpenBSD neec.esmtp.org 6.6 GENERIC.MP#3 amd64
firefox 72.0.2 (stable)
syscall 289 seems to be shmget? Just for the fun of it I added it
to the list but then firefox removes the entire line from prefs.js
-- it seems to be an invalid entry (also not listed in pledge(2)).
How can I prevent firefox from crashing for this case?
--
Address is valid for this mailing list only, please do not reply
to it direcly, but to the list.
Re: Firefox: unwanted network connections
> cloudfront.net Just for completeness: those are mozilla.net names, so I blocked that too. Thanks again for the hints/help! -- Address is valid for this mailing list only.
Re: Firefox: unwanted network connections
On Sun, Oct 20, 2019, Johnathan M. wrote:
> https://support.mozilla.org/en-US/kb/how-stop-firefox-making-automatic-connections
Thanks, I followed all of those instructions and FF is still making
the connections. I found out that those to AWS are actually for hostnames
in mozilla.com and mozaws.net domains, so I blocked those in DNS.
So far I haven't figured out what the cloudfront.net actually does/is,
I will probably try to install some proxy which hopefully can give me
that info.
> https://github.com/pyllyukko/user.js
I downloaded that and wrote a very simple script to compare the
settings with mine (see below), I will probably do the same for
prefs.js from TOR.
Thanks for all the help!
BTW: I also tried iridium and the first thing it did was to
connect to some google domain.
#!/bin/sh
fail()
{
echo "$0: $@"
exit 1
}
VERBOSE=false
while getopts v FLAG
do
case "${FLAG}" in
v) VERBOSE=true;;
esac
done
shift `expr ${OPTIND} - 1`
[ $# -ge 2 ] || fail "missing args"
OK=$1
CHK=$2
[ -s $OK ] || fail "missing $OK"
[ -s $CHK ] || fail "missing $OK"
grep '^user_pref(' $OK | \
sed -e 's/user_pref("//' \
-e 's/",[ ]*/ /' \
-e 's/).*//' |
while read K V
do
V2=`fgrep "user_pref(\"$K\"" $CHK |
sed -e 's/.*",[ ]*//' \
-e 's/[ ]*).*//'`
[ x"$V" = x"$V2" ] && continue
if [ x"$V2" = x"" ]
then
${VERBOSE} && echo "$K not set"
continue
fi
echo "$K: $V != $V2"
done
--
Address is valid for this mailing list only.
Firefox: unwanted network connections
Can someone point in me in the right direction how to prevent firefox from making lots of unwanted network connections, e.g., to amazonaws.com cloudfront.net even if I didn't open any website yet? I disabled "pingsender" and all "telemetry" options I could find, and in OpenBSD 6.5 I simply used tcpdrop on all web connections a bit after startup, but now I updated to OpenBSD 6.6 and those connections come back again and again even if just let it "sit" idle. I strongly prefer that firefox only makes network connections which I initiated instead of possibly giving away my data to some places...
Re: openssl/1.1/patches: ok to put into OpenSSL?
On Thu, Jan 31, 2019, Stuart Henderson wrote: > security/openssl/1.1/patches: patch-Configurations_10-main_conf > patch-Configurations_shared-info_pl > Unbreaks i386. Is it "ok" for OpenSSL to include these patches or is there a license problem? -- Address is valid for this mailing list only.
Re: OpenBSD 6.2/Qt 5/GC: crash: W^X violation despite wxallowed
[wxallowed as mount option solved W^X violation abort in 6.0i, but not 6.2] On Mon, Dec 04, 2017, Rafael Sadowski wrote: > Looks like you built GoldenCheetah from scratch outside the ports env. Yes; I build SW "just out of the box" (because I build the same SW on various OSs -- and a port of GoldenCheetah was submitted by someone but did not get accepted). > If yes, you have to extend ld(1)'s parameters with `-z wxneeded`. Thanks. > Please search for COMPILER_LINKS and USE_WXNEEDED in bsd.port.mk(5). That doesn't really say what to do when building things "outside the ports env". On Mon, Dec 04, 2017, Juan Francisco Cantero Hurtado wrote: > If that program is outside of the ports tree, add "-Wl,-z,wxneeded" to > the CFLAGS/CXXFLAGS. Thanks, but that causes: warning: -Wl,-z,wxneeded: 'linker' input unused [-Wunused-command-line-argument] during compilation, so adding it only to the linker seems to be better.
OpenBSD 6.2/Qt 5/GC: crash: W^X violation despite wxallowed
Back in OpenBSD 6.0 running the program from /usr/local which has wxallowed as mount option solved this problem: On Sat, Oct 15, 2016, Otto Moerbeek wrote: > On Sat, Oct 15, 2016 at 11:59:05AM -0700, Claus Assmann wrote: > > #2 0x178e9dc67db7 in WTF::OSAllocator::reserveAndCommit () > >from /usr/local/lib/qt5/libQt5WebKit.so.1.1 > smells lke a W^X violation. chekc your messages log. However, this doesn't help on OpenBSD 6.2: #0 0x0c0eb5452838 in WTFCrash () from /usr/local/lib/qt5/libQt5WebKit.so.2.1 #1 0x0c0eb52996ca in JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator () from /usr/local/lib/qt5/libQt5WebKit.so.2.1 #2 0x0c0eb529938b in JSC::ExecutableAllocator::initializeAllocator () from /usr/local/lib/qt5/libQt5WebKit.so.2.1 #3 0x0c0eb53b18bc in JSC::initializeThreading () from /usr/local/lib/qt5/libQt5WebKit.so.2.1 #4 0x0c0eb42cea69 in WebCore::ScriptController::initializeThreading () from /usr/local/lib/qt5/libQt5WebKit.so.2.1 #5 0x0c0eb4110183 in WebCore::initializeWebCoreQt () from /usr/local/lib/qt5/libQt5WebKit.so.2.1 #6 0x0c0f5a5ef402 in QWebPagePrivate::QWebPagePrivate () from /usr/local/lib/qt5/libQt5WebKitWidgets.so.2.1 #7 0x0c0f5a5f3199 in QWebPage::QWebPage () from /usr/local/lib/qt5/libQt5WebKitWidgets.so.2.1 #8 0x0c0f5a5f986f in QWebView::page () from /usr/local/lib/qt5/libQt5WebKitWidgets.so.2.1 #9 0x0c0c6498c3d6 in LTMSidebar::LTMSidebar () from /usr/local/ca/bin/GoldenCheetah #10 0x0c0c64a41ed3 in HomeView::HomeView () from /usr/local/ca/bin/GoldenCheetah #11 0x0c0c64a3ad74 in Tab::Tab () from /usr/local/ca/bin/GoldenCheetah #12 0x0c0c649a14d8 in MainWindow::MainWindow () from /usr/local/ca/bin/GoldenCheetah #13 0x0c0c647ad372 in main () from /usr/local/ca/bin/GoldenCheetah Are additional steps required to get this QT application working?
Re: ECC support for sendmail
On Mon, Jan 30, 2017, Jeremie Courreges-Anglas wrote: > I just want to stress that "FFR" means "For Future Releases". > Generally I don't think we should enable experimental features just > because we can, and I can't see why EC would be different here. It is a "non-FFR" compile time option in the 8.16.x snapshots and the other FFR has been enabled: 8.16.1/8.16.1 201X/XX/XX New compile time option TLS_EC to enable the use of elliptic curve cryptography in STARTTLS (previously available as _FFR_TLS_EC). CONFIG: New FEATURE(`tls_session_features') to enable standard rules for tls_srv_features and tls_clt_features; for details see cf/README. -- Please don't Cc: me, use only the list for replies.
Re: OpenBSD 6/Qt 5/GC: crash
On Sat, Oct 15, 2016, Otto Moerbeek wrote: > On Sat, Oct 15, 2016 at 11:59:05AM -0700, Claus Assmann wrote: > > #0 0x178ecfe55d8a in _thread_sys___syscall () at :2 > > #1 0x178ecfe4662a in *_libc_mmap (addr=Variable "addr" is not > > available. > > ) > > at /usr/src/lib/libc/sys/mmap.c:47 > > #2 0x178e9dc67db7 in WTF::OSAllocator::reserveAndCommit () > >from /usr/local/lib/qt5/libQt5WebKit.so.1.1 > smells lke a W^X violation. chekc your messages log. Thanks, that is it. I copied the binary to /usr/local and started it from there, that worked.
OpenBSD 6/Qt 5/GC: crash
Maybe someone can give me a hint how to fix/handle this problem:
GoldenCheetah crashes on OpenBSD 6.0 (amd64) when compiled against
Qt5 (installed from ports). I currently have a working version on
OpenBSD 5.3 (i386) compiled against Qt4 (from ports), but an upgrade
is a bit overdue...
$ gdb GoldenCheetah{,.core}
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "amd64-unknown-openbsd6.0"...
Core was generated by `GoldenCheetah'.
Program terminated with signal 6, Aborted.
Reading symbols from /usr/lib/libpthread.so.22.0...done.
Loaded symbols for /usr/lib/libpthread.so.22.0
Loaded symbols for
/home/ca/pd/cycling/GoldenCheetah/GoldenCheetah/src/GoldenCheetah
Reading symbols from
/home/ca/pd/cycling/GoldenCheetah/GoldenCheetah/qwt/lib/libqwt.so.6.1...done.
Loaded symbols for
/home/ca/pd/cycling/GoldenCheetah/GoldenCheetah/qwt/lib/libqwt.so.6.1
Reading symbols from /usr/lib/libz.so.5.0...done.
Loaded symbols for /usr/lib/libz.so.5.0
Reading symbols from /home/ca/OpenBSD/lib/libsrmio.so.2.0...done.
Loaded symbols for /home/ca/OpenBSD/lib/libsrmio.so.2.0
Reading symbols from /usr/local/lib/libusb.so.10.0...done.
Loaded symbols for /usr/local/lib/libusb.so.10.0
Reading symbols from /usr/local/lib/qt5/libQt5Svg.so.1.1...done.
Loaded symbols for /usr/local/lib/qt5/libQt5Svg.so.1.1
Reading symbols from /usr/local/lib/qt5/libQt5WebKitWidgets.so.1.1...done.
Loaded symbols for /usr/local/lib/qt5/libQt5WebKitWidgets.so.1.1
Reading symbols from /usr/local/lib/qt5/libQt5MultimediaWidgets.so.1.1...done.
Loaded symbols for /usr/local/lib/qt5/libQt5MultimediaWidgets.so.1.1
Reading symbols from /usr/local/lib/qt5/libQt5Widgets.so.1.1...done.
Loaded symbols for /usr/local/lib/qt5/libQt5Widgets.so.1.1
Reading symbols from /usr/local/lib/qt5/libQt5WebKit.so.1.1...done.
Loaded symbols for /usr/local/lib/qt5/libQt5WebKit.so.1.1
Reading symbols from /usr/local/lib/qt5/libQt5Multimedia.so.1.1...done.
Loaded symbols for /usr/local/lib/qt5/libQt5Multimedia.so.1.1
Reading symbols from /usr/local/lib/qt5/libQt5Gui.so.1.1...done.
Loaded symbols for /usr/local/lib/qt5/libQt5Gui.so.1.1
Reading symbols from /usr/local/lib/qt5/libQt5Xml.so.1.1...done.
Loaded symbols for /usr/local/lib/qt5/libQt5Xml.so.1.1
Reading symbols from /usr/local/lib/qt5/libQt5Sql.so.1.1...done.
Loaded symbols for /usr/local/lib/qt5/libQt5Sql.so.1.1
Reading symbols from /usr/local/lib/qt5/libQt5Network.so.1.1...done.
Loaded symbols for /usr/local/lib/qt5/libQt5Network.so.1.1
Reading symbols from /usr/local/lib/qt5/libQt5Concurrent.so.1.1...done.
Loaded symbols for /usr/local/lib/qt5/libQt5Concurrent.so.1.1
Reading symbols from /usr/local/lib/qt5/libQt5SerialPort.so.1.1...done.
Loaded symbols for /usr/local/lib/qt5/libQt5SerialPort.so.1.1
Reading symbols from /usr/local/lib/qt5/libQt5Core.so.1.1...done.
Loaded symbols for /usr/local/lib/qt5/libQt5Core.so.1.1
Reading symbols from /usr/X11R6/lib/libGL.so.17.0...done.
Loaded symbols for /usr/X11R6/lib/libGL.so.17.0
Symbols already loaded for /usr/lib/libpthread.so.22.0
Reading symbols from /usr/local/lib/libestdc++.so.17.0...done.
Loaded symbols for /usr/local/lib/libestdc++.so.17.0
Reading symbols from /usr/lib/libm.so.9.0...done.
Loaded symbols for /usr/lib/libm.so.9.0
Reading symbols from /usr/lib/libc.so.88.0...done.
Loaded symbols for /usr/lib/libc.so.88.0
Reading symbols from /usr/local/lib/qt5/libQt5PrintSupport.so.1.1...done.
Loaded symbols for /usr/local/lib/qt5/libQt5PrintSupport.so.1.1
Reading symbols from /usr/local/lib/qt5/libQt5OpenGL.so.1.1...done.
Loaded symbols for /usr/local/lib/qt5/libQt5OpenGL.so.1.1
Reading symbols from /usr/lib/libstdc++.so.57.0...done.
Loaded symbols for /usr/lib/libstdc++.so.57.0
Reading symbols from /usr/local/lib/libusb-1.0.so.1.1...done.
Loaded symbols for /usr/local/lib/libusb-1.0.so.1.1
Reading symbols from /usr/X11R6/lib/libXext.so.13.0...done.
Loaded symbols for /usr/X11R6/lib/libXext.so.13.0
Reading symbols from /usr/X11R6/lib/libX11.so.16.1...done.
Loaded symbols for /usr/X11R6/lib/libX11.so.16.1
Reading symbols from /usr/local/lib/libxslt.so.3.8...done.
Loaded symbols for /usr/local/lib/libxslt.so.3.8
Reading symbols from /usr/local/lib/libiconv.so.6.0...done.
Loaded symbols for /usr/local/lib/libiconv.so.6.0
Reading symbols from /usr/local/lib/libxml2.so.15.1...done.
Loaded symbols for /usr/local/lib/libxml2.so.15.1
Reading symbols from /usr/local/lib/libgio-2.0.so.4200.3...done.
Loaded symbols for /usr/local/lib/libgio-2.0.so.4200.3
Reading symbols from /usr/local/lib/libgstapp-1.0.so.3.0...done.
Loaded symbols for /usr/local/lib/libgstapp-1.0.so.3.0
Reading symbols from /usr/local/lib/libgstpbutils-1.0.so.3.0...done.
Loaded symbols for
Re: [mail/sendmail] SMTP session reuse bugfix
On Wed, Mar 09, 2016, Jeremie Courreges-Anglas wrote: > Claus, in the future would it be possible to prefix the patch file names > with "sendmail-"? It would be a bit safer for us, as we would not have Do you mean the patch on the sendmail.org FTP server? That naming scheme is used for about 10 years so it's unlikely to be changed now. > to check for possible collisions with other ports. Sorry, but I don't understand what "possible collisions with other ports" could happen: are the patches "global"?
[mail/sendmail] SMTP session reuse bugfix
FYI (I haven't seen this in ports yet): If sendmail tried to reuse an SMTP session which had already been closed by the server, then the connection cache could have invalid information about the session. One possible consequence was that STARTTLS was not used even if offered. The problem can be fixed by either: - applying the patch (for 8.15.2) available at ftp://ftp.sendmail.org/pub/sendmail/8.15.2.mci.p0 ftp://ftp.sendmail.org/pub/sendmail/8.15.2.mci.p0.sig - or disabling the connection cache: define(`confMCI_CACHE_SIZE', `0') The problem can be mitigated by setting at least one of these options: - using a very short timeout: define(`confMCI_CACHE_TIMEOUT', `5s') - sorting the queue by hosts: define(`confQUEUE_SORT_ORDER', `Host') Note: This issue is fixed in sendmail snapshot 8.16.0.16 (or newer) for those who would like to test upcoming releases.
Re: mail/sendmail: TLS/DH issue?
On Thu, Jun 18, 2015, Christian Weisgerber wrote: sendmail TLS/DH Interoperability Improvement https://www.freebsd.org/security/advisories/FreeBSD-EN-15:08.sendmail.asc AFAIK that advisory is being revised... Simply use '2' or your own dhparams (the latter is preferred). A new sendmail snapshot with a different solution for this problem will be available soon.
Re: sendmail tls problem openbsd 5.7
On Fri, May 22, 2015, Peter van Oord van der Vlies wrote: 2015-05-22 3:29 GMT+02:00 Claus Assmann openbsd+po...@esmtp.org: STARTTLS=server, error: accept failed=-1, reason=no shared cipher, receiving mail from which hosts? Can you find out which SW / TLS version they use? Did you restrict the cipherlist? LOCAL_CONFIG O CipherList=HIGH ... That might be a problem. But since you didn't answer the other questions, I can't help any further. Maybe someone else can... (usenet: comp.mail.sendmail ?)
Re: sendmail tls problem openbsd 5.7
On Thu, May 21, 2015, Peter van Oord van der Vlies wrote: When receiving mail i sometimes get this error when sendmail is configured with starttls. STARTTLS=server, error: accept failed=-1, reason=no shared cipher, receiving mail from which hosts? Can you find out which SW / TLS version they use? Did you restrict the cipherlist?
Re: alternatives to procmail: security
So which of the suggested alternatives (fdm, sieved, ???) have undergone a security audit or at least can claim that no problems were found when using some of those fuzzing tools? Before switching from procmail to something else it would be nice to know if that alternative is (more) secure.
Re: new: misc/GoldenCheetah
On Sun, Aug 31, 2014, Dawe wrote: I don't have any experience with train mode, does it make sense without video support? Yes. It shows real-time data if you use a USB ANT+ stick.
Re: new: misc/GoldenCheetah
On Tue, Aug 26, 2014, Dawe wrote: Otherwise it works fine for me with .fit files from my Sigma ROX 10.0 GPS exported from the Sigma datacenter software. It works with srm files, csv files (from Joule/Poweragent - I couldn't get direct downloading to work -- yet), hrm files from Polar (with some scripting), and some others. However, your version doesn't seem to use libusb hence train mode (which is pretty neat) and some other stuff wouldn't work, right? You would also need clucene to get filtering/searching. Did you get the 3D plotting to work? Sorry, I can't help with the ports stuff -- I use the git version of GoldenCheetah and fix/report problems (esp. related to OpenBSD) directly using the developers list.
