On 07/01/2019 22:26, Jordan Brown wrote:
[ Off topic for OpenSSL... ]
On 1/7/2019 8:06 AM, Jakob Bohm via openssl-users wrote:
A chroot with no other reason to open /dev/null should not contain that
file name, even on unix-like platforms (least privilege chroot design).
There's always a
[ Off topic for OpenSSL... ]
On 1/7/2019 8:06 AM, Jakob Bohm via openssl-users wrote:
> A chroot with no other reason to open /dev/null should not contain that
> file name, even on unix-like platforms (least privilege chroot design).
There's always a first reason :-)
But also: /dev/null is
On 04/01/2019 22:04, Michael Wojcik wrote:
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
Jordan Brown
Sent: Friday, January 04, 2019 13:16
If you want to, what you want is something like:
int fd;
do {
fd = open("/dev/null", O_RDWR);
On 1/4/2019 1:04 PM, Michael Wojcik wrote:
> Behavior is unfortunate if open fails, e.g. because the NFILES limit is
> reached, or because /dev/null is inaccessible (e.g. due to a
> poorly-configured chroot). You'd be better off with (fd >= 0 && fd < 3).
Yes. Oops.
--
Jordan Brown, Oracle
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
> Jordan Brown
> Sent: Friday, January 04, 2019 13:16
> If you want to, what you want is something like:
> int fd;
> do {
> fd = open("/dev/null", O_RDWR);
> } while (fd < 3);
>
On 1/4/2019 9:15 AM, Salz, Rich via openssl-users wrote:
> Jakob - you’re a star! Thanks so much, your suggestion works. So I added
> ...
> I’m wondering if this would be something worthy of attention in openssl?
>
> Maybe open an issue to catch this. Seems like the apps could
On 04/01/2019 18:15, Salz, Rich wrote:
Jakob - you’re a star! Thanks so much, your suggestion works. So I added
Maybe open an issue to catch this. Seems like the apps could check and redirect to /dev/null if the FD isn't valid.
Perhaps it is simpler to just accept invalid
Just a thought …
Do you get the same error when running the command from within a shell script
from cron [ in either bash or Korn or one of the other sh’s ] or by executing
the shell script from the command line ?
What are your default environment settings and shell for the user you are
Jakob - you’re a star! Thanks so much, your suggestion works. So I added
https://mta.openssl.org/mailman/listinfo/openssl-users
Actually, my apologies, I missed -ign_eof - that is also needed, so the
“fixed” request is:
/path/to/openssl s_client -connect :443 -servername
-tls1_3 sess_out -ign_eof https://twitter.com/tdp_org
On 04/01/2019, 10:58, "Neil Craig" wrote:
>Sorry for the delay.
>
>Jakob - you’re a star!
Sorry for the delay.
Jakob - you’re a star! Thanks so much, your suggestion works. So I added
:443 -servername
-tls1_3 sess_out https://twitter.com/tdp_org
On 03/01/2019, 14:52, "openssl-users on behalf of Jakob Bohm via
openssl-users" wrote:
>On 03/01/2019 12:52, Neil Craig wrote:
>>
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
> Jakob Bohm via openssl-users
> Sent: Thursday, January 03, 2019 09:52
> To: openssl-users@openssl.org
> Subject: Re: [openssl-users] Session params output fails via cron
>
>
> Maybe cron jobs
On 03/01/2019 12:52, Neil Craig wrote:
Thanks for the quick reply Matt. I tried -ign_eof but it had no effect,
sadly.
If anyone has any further suggestions, I¹d appreciate it very much as this
is in aid of our automated released testing for TLS1.3 on our production
traffic management service.
Two of the more common causes of cron failure are
- Environment variable missing or has different value (PATH etc)
- File permissions are different if running under root vs normal
interactive user.
Hope that helps.
--
openssl-users mailing list
To unsubscribe:
I am, yes. And as I say, it works fine interactively, it¹s just via cron
that it fails.
Neil Craig
Lead Technical Architect | Online Technology Group
Broadcast Centre, London W12 7TQ | BC4 A3
Twitter: https://twitter.com/tdp_org
On 03/01/2019, 11:56, "openssl-users on behalf of Matt
On 03/01/2019 10:31, Neil Craig wrote:
> Hi all
>
> Does anyone know why openssl (silently) fails to write session data to a file
> when run from cron? (It works fine running manually) via e.g.:
> /path/to/openssl
> s_client -connect :443 -servername -tls1_3 –sess_out
I assume you are
Thanks for the quick reply Matt. I tried -ign_eof but it had no effect,
sadly.
If anyone has any further suggestions, I¹d appreciate it very much as this
is in aid of our automated released testing for TLS1.3 on our production
traffic management service.
Cheers
Neil Craig
Lead Technical
On 03/01/2019 10:31, Neil Craig wrote:
> Hi all
>
> Does anyone know why openssl (silently) fails to write session data to a file
> when run from cron? (It works fine running manually) via e.g.:
> /path/to/openssl
> s_client -connect :443 -servername -tls1_3 –sess_out
>
> Running the same
Hi all
Does anyone know why openssl (silently) fails to write session data to a file
when run from cron? (It works fine running manually) via e.g.: /path/to/openssl
s_client -connect :443 -servername -tls1_3 –sess_out
Running the same command but with –tls1_2 works fine from cron. This feels
19 matches
Mail list logo
