Re: ipfilter fails to compile WITHOUT_INET6
On 22.06.2017 21:20, Cy Schubert wrote: Can you try the attached patch please? Yes, replacing: -#ifdef AF_INET6 +#ifdef USE_INET6 lets the build succeed. Is it Ok to modify stuff under contrib/ though?.. -mi ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Locking console with Ctrl-S hangs various processes (ttydcd)
Hello! A fellow FreeBSD user was recently confounded by a problem: various processes on his 10.0 system were hanging or otherwise misbehaving: su, certain daemons, syslogd. They were all hung in the ttydcd-state. Searching https://www.google.com/search?q=FreeBSD+ttydcd for that revealed only, that other people have seen the problem, but nobody (including the entire freebsd-stable@ on 2012 http://lists.freebsd.org/pipermail/freebsd-stable/2012-June/068281.html) was able to offer a solution. Apparently, the problem stems from the ttyv0 (which moonlights as /dev/console for the vast majority of installs) being locked -- such as by pressing Ctrl-S. One needs not be a root to do it... After that, any attempts to write to /dev/console -- which even syslog(3) often does -- would hang the calling process until the tty is unlocked (such as with Ctrl-Q). This may be the desired behavior for normal ttys, but, perhaps, /dev/console should act differently? -mi ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: md2 on current and 10.
On 08.01.2014 02:54, Peter Wemm wrote: Could we, please, have MD2 resurrected before 10.0 is officially out? Preferably in both -lmd and -lcrypto, but certainly in the former. Thank you! Yours, The time to bring this up was before the freeze for 10.0, a good 6+ months ago. It is way too late now. First of all, Peter, are you talking as a core-member, or expressing personal opinion? In any case, I'd say it is not entirely fair to blame me for reporting a problem late -- without any apologies about causing it in the first place... But is it really too late to add such a small piece back to where it was? I'm not talking about resurrecting uucp here... Meanwhile, any existing MD2-using application will simply break after upgrade -- does that not bother anyone? If the code was removed after 19 years in the tree, is 6 months really too late to resurrect it? However.. the code in libmd had had a non-commercial use restriction.. Even if it wasn't too late, that code won't be back. That restriction was not (enough of) a problem for 20 years (since 1994) -- and still is not in 9.x and 8.x. But, Ok... Your best bet is to create a crypto/libmd2 port. Start with the code from openssl. Adding such a port increases the number of hoops for any user to jump through -- and the maintenance costs. Whereas the cost of simply adjusting the base OpenSSL's configuration to include MD2 functionality is virtually zero -- a single additional file file will be back (md2.h), and no new libraries... OpenSSL port offers MD2 as an option -- surely the base version can have that same option flipped on without breaking anything. Yours, -mi ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: md2 on current and 10.
On 08.01.2014 20:05, Peter Wemm wrote: The path of least resistance is to make a libmd2 port. It's the only way I can see you getting to use it on 10.0. *I* don't really care. *I* don't use md2 myself. I became aware of the problem by accident -- because one of my ports was affected (tcl-trf). But I can fix the port, no huhu. It just seems to me, FreeBSD as a project goofed by abruptly removing the functions, that have been in the base for many years. But if the src-committers don't care to ungoof it -- despite my raising awareness as much (and, perhaps, even above) as permissible by politeness -- then so be it... Yours, -mi ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: md2 on current and 10.
On 27.12.2013 10:50, Ulrich Spörlein wrote: In other words, /if you like your digest algorithm, you can keep it/. Yours, Seconded. What should people use if some of their old data is using MD2 for verification? How can they now easily check that their data (from tape or whatever) still matches the fingerprint? Was it too naive of Ulrich and myself to expect the seconded and unopposed motion to be acted upon? Or, at least, put to a vote? -mi ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: md2 on current and 10.
On 20.12.2013 13:38, olli hauer wrote: md2 was deprecated in 2009 by the openssl project http://cvs.openssl.org/chngview?cn=18381 CVE-2009-2409 As fas as I know some Linux based projects have removed md2 from openssl-0.9.x in 2009. So, when are we removing sum(1) and cksum(1) -- implementation of the even weaker hashing? Should we do with rsh(1), what Linux have done: % rsh -v OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 Mar 2012 usage: ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec] [-D [bind_address:]port] [-e escape_char] [-F configfile] [-I pkcs11] [-i identity_file] [-L [bind_address:]port:host:hostport] [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port] [-R [bind_address:]port:host:hostport] [-S ctl_path] [-W host:port] [-w local_tun[:remote_tun]] [user@]hostname [command] How about rexec/rcmd(3), gets(3), and tmpfile(3)? OpenSSL may have deprecated md2 (though it remains an option even there, just off by default), but FreeBSD did not have to -- our libmd could've continued to offer the functionality, just as libz, for yet another example, continues to offer its own checksum implementation. If, for some reason, we feel we must warn the user, we could do that when installing ports -- as we already warn about the network-listening and other potentially dangerous functions. Could we, please, have MD2 resurrected before 10.0 is officially out? Preferably in both -lmd and -lcrypto, but certainly in the former. Thank you! Yours, -mi ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: md2 on current and 10.
On 20.12.2013 12:52, olli hauer wrote: Hm the config script tests for md2 and sha1 ... What happens if md2 support is removed from the code? Yes, the md2 can be removed from the set of digests made available by the port -- that's not a problem. What I wanted to know, was why? Maybe, the header files should've been replaced with ones containing an #error (like malloc.h was)... Oh well... -mi ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: md2 on current and 10.
Thinking more about the MD2, I'd say, FreeBSD should not have removed the algorithm. Although no longer deemed sufficiently secure, it is still in use and people using it on FreeBSD-8.x and 9.x today may wish to continue doing so after upgrading to 10.x In the old Mechanism vs. Policy debate http://en.wikipedia.org/wiki/Separation_of_mechanism_and_policy we erred on the side of policy and it does not seem right... Whether or not to use MD2 is (or should be) left up to the users of FreeBSD. Even if OpenSSL no longer provides it, libmd should continue to. In other words, /if you like your digest algorithm, you can keep it/. Yours, -mi ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
md2 on current and 10.
It would appear, neither md2.h nor openssl/md2.h are any longer available on FreeBSD current and 10.x This breaks the devel/tcl-trf port, which I maintain... Could someone, please, comment? Should I patch-up the port to disable the functionality? Or?.. Thank you! -mi ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
patch -p broken on HEAD?
On 30.11.2013 13:24, pkg-fall...@freebsd.org wrote: === Applying FreeBSD patches for xmdiary-3.0.3_3 removing the malloc.h includes /bin/sh /usr/ports/deskutils/xmdiary/scripts/nomalloc /wrkdirs/usr/ports/deskutils/xmdiary/work/xmdiary-3.0.3 21 /dev/zero patch: option requires an argument -- p usage: patch [-bCcEeflNnRstuv] [-B backup-prefix] [-D symbol] [-d directory] [-F max-fuzz] [-i patchfile] [-o out-file] [-p strip-count] [-r rej-name] [-V t | nil | never] [-x number] [-z backup-ext] [--posix] [origfile [patchfile]] patch patchfile patch: option requires an argument -- p It looks like the -p option can no longer be given to patch(1) by itself. Is this deliberate? Thanks, -mi ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ports include /etc/src.conf? i.e. graphics/libfpx
14.02.2013 09:34, Peter Pentchev ???(??): However, there is then the argument of well, if you want to use the bsd.*.mk infrastructure, then why don't you just copy it into your project and include it from there - just like many, many projects do with, say, the sys/queue.h header, or parts of libc, or whatever? And it is, indeed, a very good argument Either I completely misunderstand the argument, or I disagree -- strongly -- with it. Including bits created and maintained by others into your own project is very rarely justified (although done quite often). I don't see, why adding (some version of) bsd.lib.mk and friends into every project, that wishes to build a shared library on FreeBSD, is any more justified, than bundling libjpeg with every graphics application. John-Mark also just posted a strong argument for using the existing bsd.*.mk family of makefiles... since this is how a software distribution's parts are supposed to be used - you copy them into your project and use them even when they are not available on the host system. So one might argue that the port is, indeed, buggy, that the src.conf documentation is, indeed, correct, and that the proper way for people to use the bsd.*.mk The documentation is, demonstrably, incorrect -- it was incorrect, when it was written 7 years ago, and remains so. Because a user of bsd.*.mk /will be/ affected by src.conf -- unless he takes special steps to prevent it. This fact can not be fixed by a user, the only way to avoid the effect, is to modify their own makefile(s). The implementation of the change may be blamed for this -- if, indeed, there was a need for src-only configuration knobs, src.conf should be included, when a special flag is present in the environment (put there by src/Makefile), not the other way around. some weird src.conf settings might confuse the build of some of my software on FreeBSD. And some of those settings are required for healthy building of some of the ports... For example, libreoffice knows out of the box, that FreeBSD has Kerberos libraries. So, if your world was built WITHOUT_KERBEROS and WITHOUT_GSSAPI, libreoffice fails to configure. A simple patch like: +.if defined(WITHOUT_KERBEROS) +CONFIGURE_ARGS+= --without-krb5 +.endif +.if defined(WITHOUT_GSSAPI) +CONFIGURE_ARGS+= --without-gssapi +.endif could help, but WITHOUT_KERBEROS and WITHOUT_GSSAPI are set in src.conf and not, normally, available to the ports... So, in my opinion, the manual (src.conf(5)) should be updated to reflect reality. Or, if the separation is really deemed desirable (something I, for one, continue to question), the implementation (in /usr/src/Makefile and bsd.own.mk) needs to be altered to only consider src.conf, when world/kernel are being built/installed. -mi ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ports include /etc/src.conf? i.e. graphics/libfpx
15.02.2013 19:12, Ian Lepore ???(??): The src.conf manpage is not in error. The intent is that src.conf applies only to the building of the freebsd world and kernel, that is, the source that's usually located under /usr/src. If settings from src.conf are leaking into other builds, the error is in the makefiles, not in the manpage. Unambiguous evidence of this can be found in the email announcing the new src.conf file and why it was created: http://lists.freebsd.org/pipermail/freebsd-current/2006-March/061725.html I'm not an expert with the build system, and that goes double for ports, so I can't say exact how or why it's broken, or when the breakage happened (or even if it's been broken from the very beginning), but I think that announcement email makes it clear the bug isn't the documentation. Thank you, sir, for posting the link. Once I read it, however, I am puzzled. Because, contrary to what you are saying,it makes no statement about whether or not knobs in src.conf are (or are not) supposed to affect makefiles outside of /usr/src. The only paragraph mentioning the new file says: - Options can be passed on the make(1) command line or in the new /etc/src.conf (overrideable). The reason for the new src.conf is so we keep make(1) environment clean from these variables outside world/kernel builds (make.conf pollutes the environment as it's included by sys.mk). I fail to see, where in the above it says, that a private project's /home/ian/foo/BSDmakefile is not supposed to be affected by the system's /etc/src.conf. Do you? There may be other reasons for src.conf(5) to claim, what it claims about the file's only purpose, but the e-mail you referred to is not one of them. -mi ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Re: ports include /etc/src.conf? i.e. graphics/libfpx
13.02.2013 11:22, O. Hartmann написав(ла): If this is taken literally then could it be said that ports that use bsd.lib.mk are broken because they are using makefile includes from the source tree? -Kimmo For one, the particular port (its Makefile.bsd) was created in 2001, five years before src.conf appeared. The intent of creating a separate src.conf, I believe, was to shield a world-build from crazy options someone could've put into their make.conf for the benefit of building a port or two... But I may be mistaken. I would consider them broken! On the contrary. I wish, more ports were using the system's bsd.*.mk collection -- instead of the godawful autoconf, for example. What does the port's Makefile.bsd say? It says: These are the sources, this is the name of the library I want. Please, create it. That's all... It is how things are supposed to be, in my opinion. If the bsd.*.mk collection was not meant to be used outside of /usr/src, then it wouldn't be installed (under /usr/share/mk) for the decades, that BSD exists. Maybe, the bsd.*.mk collection should be smarter -- and not include src.conf -- when .CURDIR is outside of /usr/src. I'm not sure... How could I track down problems if they are results of intermixed config files when the manpage explicitely tells me, that the /etc/src.conf is only for the build of the operating system? If the manual says that, it is incorrect -- if only because it does not reflect (as you've experienced) the practice, that existed long before the manual was written. As for your tracking down problems, I'd say, it should be very easy for you to recognize the flags you've added by hand -- even if you've added them to where you believed, they would not affect a port. -mi ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ports include /etc/src.conf? i.e. graphics/libfpx
14.02.2013 08:02, Tom Evans написав(ла): I think src.conf is meant only to be included when building src. For example, bsd.port.mk sets _WITHOUT_SRCCONF before including bsd.own.mk (which is the makefile that includes src.conf). It's done this since src.conf was added in 2006, so evidently ports are, by design, not supposed to include src.conf. Awesome. All that's missing then, is for _WITHOUT_SRCCONF to be automatically added to MAKE_ENV... I would consider them broken! On the contrary. I wish, more ports were using the system's bsd.*.mk collection -- instead of the godawful autoconf, for example. Er? What port uses autoconf for driving the building the port? A lot of ports have build systems that use autoconf, but determining how to build is always driven by *.mk. I don't think part of porting to FreeBSD should be rewriting how the package builds itself. Hundreds of ports rely on auto-something bundled with the vendor's sources, that's what I meant. As for how to build a particular package, that's up to the port-maintainer. Either the documentation is wrong, and should be changed, or this singular port is not behaving as it should. I may sound defensive here, but I'll still repeat, that this singular port (and I do, in fact, have other ones like it) started using bsd.lib.mk 5 years before src.conf (and its man-page) was added to the tree. -mi ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ports include /etc/src.conf? i.e. graphics/libfpx
14.02.2013 08:55, Tom Evans написав(ла):
On Thu, Feb 14, 2013 at 1:12 PM, Mikhail T. mi+t...@aldan.algebra.com wrote:
I may sound defensive here, but I'll still repeat, that this singular
port
(and I do, in fact, have other ones like it) started using bsd.lib.mk 5
years before src.conf (and its man-page) was added to the tree.
This is true. But what is the bug, that the port's Makefile.bsd was
not updated on the introduction of src.conf to DTRT (and no-one
noticed for 7 years), or that the purpose of src.conf has been
mistakenly documented for 7 years?
I think, the bug is either in documentation or implementation of
src.conf (if it had to be implemented at all, that is) -- there was
never (and still is not) any suggestion, that bsd.{prog,lib}.mk are not
supposed to be used by other people's software.
Maybe, if the file is really meant to be used by *world and *kernel
targets, the knob should've been _WITH_SRCONF -- and added to the
environment by src/Makefile? Because, forget ports for a second, what if
my own little project uses bsd.prog.mk -- because Makefiles using it
tend to fit in a window without scrolling?
I'd say, the documentation should be updated to state, that src.conf
will affect anything, that uses bsd.*.mk family of makefiles, unless
_WITHOUT_SRCCONF is set. The entire /usr/src as well as some of the
ports may then be listed as examples of the areas affected. This will
reflect reality and help avoid frustration that O. Hartmann went through.
-mi
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
