Re: openssl 1.1.1 utils mkerr.pl
On January 16, 2019 9:52:26 AM PST, Enji Cooper wrote: > >> On Jan 15, 2019, at 5:55 PM, David Cornejo wrote: >> >> Hi, >> >> I am working on some code that wants to use mkerr.pl from the openssl >> distribution - but this appears to have been left out of the import >to >> base. >> >> Is there an alternative method to create the include files produced >> from this script in FreeBSD? > > >Hi Dave, > >I would go a different route from what was mentioned by others — I >would actually either grab mkerr.pl from upstream from the release >package (upstream on GitHub is >https://github.com/openssl/openssl/releases ) (sidenote: I don’t know >why, but our vendor-crypto tree lacks this script as well; jkim@ CCed). >Why go this route? You can easily grab the file using a tool like curl, >fetch, or wget from GitHub, and you can be sure that the version you’re >grabbing is the upstream release version. The only downside of this >route is that you might have to apply local patches in order to fix >bugs with the script itself (which the port would handle), and you’ll >have to grab all dependencies (in this case/version: configdata.pm, >which is generated from the release). Example: > >fetch -o mkerr.pl >https://raw.githubusercontent.com/openssl/openssl/d1c28d791a7391a8dc101713cd8646df96491d03/util/mkerr.pl > >I think that these files should be committed in the vendor-crypto tree, >along with crypto/openssl ; although FreeBSD as a project doesn’t have >much value for these files, other repackagers do have value for these >files (Isilon had to recompile openssl to deal with some modifications >to the library for FIPS compliance). > >Why am I not recommending the port outright? Depending on which version >of openssl you’re based on, you might need to maintain a >Frankensteinian version of the port to deal with the current (or old) >ports framework, which can be… noisome (speaking from experience having >dealt with this at Isilon with a 3 year old port system in the past). >Plus, some of the config might differ (—prefix, etc), causing the >version you’re configuring to differ from the base system version. > >Alternatively, you could just bypass openssl in base and patch a copy >from ports and be done with it. > >Cheers, >-Enji The file is likely used in the generation of an error table prior to the upstream packaging the tarball. We as consumers of the software don't need though. Possible options might be that the OP maintain the file himself or develop a port which installs just this file. I don't recommend the second option. Why this specific file? There are other apps that perform the same function, like compile_et that is distributed with MIT KRB5 and Heimdal, and installed. -- Pardon the typos and autocorrect, small keyboard in use. Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ 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"
Re: openssl 1.1.1 utils mkerr.pl
On Wed, Jan 16, 2019 at 7:54 AM Benjamin Kaduk wrote: > > On Wed, Jan 16, 2019 at 09:52:26AM -0800, Enji Cooper wrote: > > > > > On Jan 15, 2019, at 5:55 PM, David Cornejo wrote: > > > > > > Hi, > > > > > > I am working on some code that wants to use mkerr.pl from the openssl > > > distribution - but this appears to have been left out of the import to > > > base. > > > > > > Is there an alternative method to create the include files produced > > > from this script in FreeBSD? > > > > > > Hi Dave, > > > > I would go a different route from what was mentioned by others — I would > > actually either grab mkerr.pl from upstream from the release package > > (upstream on GitHub is https://github.com/openssl/openssl/releases ) > > (sidenote: I don’t know why, but our vendor-crypto tree lacks this script > > as well; jkim@ CCed). Why go this route? You can easily grab the file > > The script is used by upstream when preparing a release; we only use the > finished release objects from upstream and do not expect to be doing this > sort of "pre-release" step in our own operations. > > -Ben thanks for the responses! Let's say that this might become a port, so I'd create the output files from mkerr.pl by pulling that script from upstream and then include them in the files directory for installation? thanks, dave c -- Kailua, Hawaiʻi US +1 (808) 728-3050 UK +44 (020) 3286 2808 ___ 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"
Re: openssl 1.1.1 utils mkerr.pl
On Wed, Jan 16, 2019 at 09:52:26AM -0800, Enji Cooper wrote: > > > On Jan 15, 2019, at 5:55 PM, David Cornejo wrote: > > > > Hi, > > > > I am working on some code that wants to use mkerr.pl from the openssl > > distribution - but this appears to have been left out of the import to > > base. > > > > Is there an alternative method to create the include files produced > > from this script in FreeBSD? > > > Hi Dave, > > I would go a different route from what was mentioned by others — I would > actually either grab mkerr.pl from upstream from the release package > (upstream on GitHub is https://github.com/openssl/openssl/releases ) > (sidenote: I don’t know why, but our vendor-crypto tree lacks this script > as well; jkim@ CCed). Why go this route? You can easily grab the file The script is used by upstream when preparing a release; we only use the finished release objects from upstream and do not expect to be doing this sort of "pre-release" step in our own operations. -Ben ___ 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"
Re: openssl 1.1.1 utils mkerr.pl
> On Jan 15, 2019, at 5:55 PM, David Cornejo wrote: > > Hi, > > I am working on some code that wants to use mkerr.pl from the openssl > distribution - but this appears to have been left out of the import to > base. > > Is there an alternative method to create the include files produced > from this script in FreeBSD? Hi Dave, I would go a different route from what was mentioned by others — I would actually either grab mkerr.pl from upstream from the release package (upstream on GitHub is https://github.com/openssl/openssl/releases ) (sidenote: I don’t know why, but our vendor-crypto tree lacks this script as well; jkim@ CCed). Why go this route? You can easily grab the file using a tool like curl, fetch, or wget from GitHub, and you can be sure that the version you’re grabbing is the upstream release version. The only downside of this route is that you might have to apply local patches in order to fix bugs with the script itself (which the port would handle), and you’ll have to grab all dependencies (in this case/version: configdata.pm, which is generated from the release). Example: fetch -o mkerr.pl https://raw.githubusercontent.com/openssl/openssl/d1c28d791a7391a8dc101713cd8646df96491d03/util/mkerr.pl I think that these files should be committed in the vendor-crypto tree, along with crypto/openssl ; although FreeBSD as a project doesn’t have much value for these files, other repackagers do have value for these files (Isilon had to recompile openssl to deal with some modifications to the library for FIPS compliance). Why am I not recommending the port outright? Depending on which version of openssl you’re based on, you might need to maintain a Frankensteinian version of the port to deal with the current (or old) ports framework, which can be… noisome (speaking from experience having dealt with this at Isilon with a 3 year old port system in the past). Plus, some of the config might differ (—prefix, etc), causing the version you’re configuring to differ from the base system version. Alternatively, you could just bypass openssl in base and patch a copy from ports and be done with it. Cheers, -Enji signature.asc Description: Message signed with OpenPGP
Re: CUPS: [Client 1] Unable to encrypt connection: An illegal parameter has been received.
On Wed, 16 Jan 2019 15:23:40 +0100 "O. Hartmann" wrote: > We have an experimental IPV6 network and within this network, FreebSD CURRENT > (r343087) is acting as a CUPS print server, while a bunch FreeBSD 12-STABLE > boxes are CUPS clients. > > The setup, so far, worked with IPv4. Introducing IPv6 addresses on both server > and host results in the error > > [Client 1] Unable to encrypt connection: An illegal parameter has been > received. > > In file cups/client.conf we address the appropriate printer via > > ipps://xxx.xxx.xxx.xxx/printers/printer_name (IPv4 of the CUPS server host) > > This works fine. > > But ipps://[::::]/printers/printer_name (IPv6 of the CUPS > server host) doesn't work and results in the error on the server as shown > above. > > I fiddled also around with the SSLOption parameter in client.conf and > parallel, > to match requiremets, in cups/cupsd.conf of the server host - with no effect. > > On the server side, it seems that all the documents I could pick up from > cups.org or Apple do not specify any IPv6 address in an "Allow from" > statement: > everything seems to be stuck with IPv4. While the cupsd.conf SSLListen option > is for IPv6 > > SSLListen [fd01:dead:beef::affe]:631 > > which works, I get an error when trying to put anything IPv6-similar with the > convention with the brackets "[" and "]" in a "Allow from" option in the > sections where I need to restrict access. An IPv6 without "[" and "]" seems to > be accepted - but when coemmnting out ANY IPv4 address and leaving only IPV6 > in > the "Allow from " statement, no remote connection is allowed. > > This drives me nuts. Since the aim will be to have a printing facility within > a > IPv6 only network, I feel a bit lost. > > Does anyone have had similar problems? cupsd.conf(5) does mention "Allow [ipv6-address]" in the section: DIRECTIVES VALID WITHIN LOCATION AND LIMIT SECTIONS With client.conf you can configure libcups so it talks to a remote CUPS server instead of the local one. This has been deprecated for years so I suspect there hasn't been any development on it and that it simply doesn't support IPv6. What you're supposed to do instead is run a cupsd on the client and add the print server as a network printer (using your ipps URI). When you have to choose the make of the printer choose Raw so you don't need a PPD and cupsd will forward the job to the server without doing any filtering. You can set this up on one client and then copy the cups configuration in /usr/local/etc/cups to the other clients. Running a local cupsd allows clients to queue print jobs when the print server is down. Alternatively you can let the print server announce the printer via Bonjour/Avahi (Browsing on in cupsd.conf) and run cups-browsed from print/cups-filters on the clients which will then detect the print server and add a raw print queue automatically. This can be convenient for laptops that move between networks. ___ 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"
CUPS: [Client 1] Unable to encrypt connection: An illegal parameter has been received.
We have an experimental IPV6 network and within this network, FreebSD CURRENT (r343087) is acting as a CUPS print server, while a bunch FreeBSD 12-STABLE boxes are CUPS clients. The setup, so far, worked with IPv4. Introducing IPv6 addresses on both server and host results in the error [Client 1] Unable to encrypt connection: An illegal parameter has been received. In file cups/client.conf we address the appropriate printer via ipps://xxx.xxx.xxx.xxx/printers/printer_name (IPv4 of the CUPS server host) This works fine. But ipps://[::::]/printers/printer_name (IPv6 of the CUPS server host) doesn't work and results in the error on the server as shown above. I fiddled also around with the SSLOption parameter in client.conf and parallel, to match requiremets, in cups/cupsd.conf of the server host - with no effect. On the server side, it seems that all the documents I could pick up from cups.org or Apple do not specify any IPv6 address in an "Allow from" statement: everything seems to be stuck with IPv4. While the cupsd.conf SSLListen option is for IPv6 SSLListen [fd01:dead:beef::affe]:631 which works, I get an error when trying to put anything IPv6-similar with the convention with the brackets "[" and "]" in a "Allow from" option in the sections where I need to restrict access. An IPv6 without "[" and "]" seems to be accepted - but when coemmnting out ANY IPv4 address and leaving only IPV6 in the "Allow from " statement, no remote connection is allowed. This drives me nuts. Since the aim will be to have a printing facility within a IPv6 only network, I feel a bit lost. Does anyone have had similar problems? Regards, Oliver ___ 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"
Re: openssl 1.1.1 utils mkerr.pl
> Hi! > > > Did you try to use the openssl port? > > cd security/openssl111 > $ grep mkerr pkg-plist > $ cd secuirty/openssl111 make extract find work | grep mkerr > does not have it, either. > -- Rod Grimes rgri...@freebsd.org ___ 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"
Re: openssl 1.1.1 utils mkerr.pl
On January 15, 2019 5:55:34 PM PST, David Cornejo wrote: >Hi, > >I am working on some code that wants to use mkerr.pl from the openssl >distribution - but this appears to have been left out of the import to >base. > >Is there an alternative method to create the include files produced >from this script in FreeBSD? Check out the port. However the file isn't installed by it. Make extract. You should find it there. -- Pardon the typos and autocorrect, small keyboard in use. Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ 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"
Re: openssl 1.1.1 utils mkerr.pl
Hi! > Did you try to use the openssl port? cd security/openssl111 $ grep mkerr pkg-plist $ does not have it, either. -- p...@freebsd.org +49 171 3101372 One year to go ! ___ 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"
Re: openssl 1.1.1 utils mkerr.pl
Did you try to use the openssl port? Ronald. Van: David Cornejo Datum: woensdag, 16 januari 2019 02:55 Aan: FreeBSD Current Onderwerp: openssl 1.1.1 utils mkerr.pl Hi, I am working on some code that wants to use mkerr.pl from the openssl distribution - but this appears to have been left out of the import to base. Is there an alternative method to create the include files produced from this script in FreeBSD? thanks, dave c -- Kailua, Hawai?i US +1 (808) 728-3050 UK +44 (020) 3286 2808 ___ 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" ___ 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"
