>What's the reason for using malloc(3) in the first place? Is this a
> limitation
of the library or just openssl cms ?
It is a limitation of the CMS command. You might look at the -stream option.
If you need more then that, well, a PR is also welcomed.
--
openssl-users mailing
On 07/30/2018 12:52 PM, Jordan Brown wrote:
Because a zero-leaks policy is a lot easier to manage than having to
make a judgement call on each leak whether or not it's important, and
having to filter out "unimportant" leaks when you're trying to find
out whether you've introduced any
On 7/30/2018 1:57 AM, Christian Böhme wrote:
> What's the reason for using malloc(3) in the first place? Is this a
> limitation of the library or just openssl cms ?
>
> For the latter, if the argument to -in can be determined to resolve to
> a file descriptor of a regular file, the file's contents
On 7/30/2018 7:18 AM, Michael Wojcik wrote:
> I don't know why people worry about singleton memory "leaks". If the
> leak isn't growing over the lifetime of the process, it's not causing
> any trouble. I've seen some teams obsessing about getting clean
> reports from dynamic-analysis tools like
> I never thought I'd see the day that someone would have to defend not leaking
> memory in pivotal security code like openssl however
To be accurate, it was a couple of people saying that memory leaks *on process
exit* aren’t be a big deal.
--
openssl-users mailing list
To unsubscribe:
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of Christian Böhme
> Sent: Monday, July 30, 2018 02:57
>
> For the latter, if the argument to -in can be determined to resolve to a
> file
> descriptor of a regular file, the file's contents can be /very/ conveniently
> On Jul 30, 2018, at 8:26 AM, Graham Leggett wrote:
>
> Should they suppress attempts to unload mod_ssl, apr_crypto_openssl, libpq,
> libldap, etc if we know for sure that openssl < 1.1.0 is linked to them?
My recommendation is never unload a library once loaded.
I don't see the point,
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of Viktor Dukhovni
> Sent: Monday, July 30, 2018 08:02
>
> My recommendation is never unload a library once loaded.
I agree, at least in most cases.
I don't know why people worry about singleton memory "leaks". If the
On 24 Jul 2018, at 18:06, Viktor Dukhovni wrote:
>> Or is it correct in v1.1.0 and above to just not initialise anything at all,
>> not clean anything up at all, and expect openssl to “do the right thing”
>> when mod_ssl is unloaded?
>
> Yes. And *especially* when the code that depends on
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
> Jordan Brown
> Sent: Monday, July 30, 2018 10:46
> I have never heard of a malloc implementation that has artificial limits;
Er... setrlimit(RLIMIT_DATA). For OSes that claim Single UNIX Specification
compliance.
> On Jul 30, 2018, at 12:46 PM, Jordan Brown
> wrote:
>
> If you can't malloc the space, you probably can't mmap it either. I have
> never heard of a malloc implementation that has artificial limits; if it's
> failing it's because it can't find that much contiguous virtual address
>
On 07/30/2018 01:27 PM, Salz, Rich via openssl-users wrote:
> I never thought I'd see the day that someone would have to defend
not leaking memory in pivotal security code like openssl however
To be accurate, it was a couple of people saying that memory leaks *on
process exit* aren’t be a
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
> Salz, Rich via openssl-users
> Sent: Monday, July 30, 2018 11:28
> > I never thought I'd see the day that someone would have to defend not
> > leaking memory
> > in pivotal security code like openssl however
> To
On 07/30/2018 02:34 PM, Salz, Rich via openssl-users wrote:
* So why not just have a rule "don't litter"
Have you looked at, say, the memleak testing we do?
Thanks for the two cents.
Of course I applaud the team's memleak testing! How could my post be
interpreted otherwise? I wasn't
> On Jul 30, 2018, at 3:43 PM, Marty G wrote:
>
>> Spending valuable cycles to eliminate these is not the most productive
>> use of our time.
I meant "developer cycles", not CPU cycles.
> How often does a process exit? Only once.
--
Viktor.
--
openssl-users mailing list
To
On 07/30/2018 03:27 PM, Viktor Dukhovni wrote:
The only time such "leaks" come into play is process exit and library
unload. My advice is to not unload the library and to accept the
fact that a small fixed amount of memory might not be deallocated
at exit. Typically, even "valgrind" will not
* So why not just have a rule "don't litter"
Have you looked at, say, the memleak testing we do?
Thanks for the two cents.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
By the way, these responses have been very thoughtful. I just wanted to
say thanks!
/*
* Michael R. Hines
* Staff Engineer, DigitalOcean.
*/
On 07/28/2018 08:44 AM, Michael Wojcik wrote:
From: Michael R. Hines [mailto:mrhi...@digitalocean.com]
Sent: Friday, July 27, 2018 19:06
Forgive the
> On Jul 30, 2018, at 3:00 PM, Marty G wrote:
>
> Of course I applaud the team's memleak testing! How could my post be
> interpreted otherwise? I wasn't trying to single anyone out, just the
> general idea that any memory leak is of little concern when the implications
> of the leak
On 7/30/2018 11:12 AM, Michael Wojcik wrote:
> As for Jordan's objection: If you don't know the source of your
> "leaks", then I can't say I'm particularly impressed with a
> zero-"leak" policy. That amounts to "let's burn a lot of cycles during
> process termination, rather than understand what
On 7/30/2018 12:27 PM, Viktor Dukhovni wrote:
> The only time such "leaks" come into play is process exit and library
> unload.
Process exit is not the only time that libraries get unloaded. I don't
happen to remember any details, but I know we've had problems with
libraries that got unloaded
On 28.07.2018 22:27, Salz, Rich via openssl-users wrote:
>>It would appear that both commands fail due to them being unable to
> allocate more memory to slurp the rest of the input file's contents into.
> Is this intentional behaviour?
>
> It is a known issue.
What's the reason
On Fri, 2018-07-27 at 12:49 -0400, Robert Moskowitz wrote:
>
> On 07/27/2018 12:35 PM, Viktor Dukhovni wrote:
> >
> > > On Jul 27, 2018, at 11:25 AM, Robert Moskowitz > > om> wrote:
> > >
> > > 3064446992:error:2006D080:BIO routines:BIO_new_file:no such
> > > file:crypto/bio/bss_file.c:79:
> >
23 matches
Mail list logo
