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 firs
[ 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 par
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 Sol
> 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);
> clo
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 che
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 stdi
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
execut
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! T
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:
>> Tha
> 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.
C
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: https://mta.opens
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 Caswell"
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 actuall
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 Architec
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 com
18 matches
Mail list logo
