Re: [openssl-users] Initialising OpenSSL more than once - how do we handle this?

[Jordan Brown]

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 we're doing".

*Fully* understanding the implications of a bug can be quite difficult. 
Often it is much easier to observe that there is a clear bug, fix it,
and move along.  Are there cases where this particular leak is a
problem?  Just because the developer can't think of any doesn't mean
that there are none.  Is it better to spend developer effort proving
that a particular leak is harmless, or fixing it?

And that doesn't consider the cost to the *next* developer, who runs a
leak test, finds a dozen leaks, and then needs to research each one to
be sure that it isn't a result of their change.

-- 
Jordan Brown, Oracle Solaris

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Initialising OpenSSL more than once - how do we handle this?

[Jordan Brown]

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 because they were dependencies of other
shared objects that are intended to be used on a "load, call, unload" basis.

-- 
Jordan Brown, Oracle Solaris

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Initialising OpenSSL more than once - how do we handle this?

[Viktor Dukhovni]

> 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 unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Initialising OpenSSL more than once - how do we handle this?

[Marty G]

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 report "leaks" for
addresses that are still referenced, so the static allocations
are not a problem.

Spending valuable cycles to eliminate these is not the most productive
use of our time.

How often does a process exit?  Only once.  After a process running for 
billions of cycles in thousands or millions of loops and whatnot I 
hardly think the relative few at the end for clean up could remotely be 
considered "valuable" relative to the total number of cycles executed in 
life of the process.  Unless you are talking about developer's time and 
not the processes time.  In which case I still disagree, but it is your 
time not mine so I won't go there.  I think the forest is being missed 
for the trees here, but I'm going to bow out as I've said my piece

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Initialising OpenSSL more than once - how do we handle this?

[Viktor Dukhovni]

> 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 aren't fully known if the cause of the leak isn't known, and if 
> one knows the cause, why not deal with it as simple good practice?  

One time initialization that allocates an object for the lifetime
of the process has justifiably not been considered a "leak".
Refactoring code to enable exit-time deallocation of static allocated
objects is mostly fruitless work.

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 report "leaks" for
addresses that are still referenced, so the static allocations
are not a problem.

Spending valuable cycles to eliminate these is not the most productive
use of our time.

-- 
Viktor.

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Initialising OpenSSL more than once - how do we handle this?

[Marty G]

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 trying to single anyone out, just the 
general idea that any memory leak is of little concern when the 
implications of the leak aren't fully known if the cause of the leak 
isn't known, and if one knows the cause, why not deal with it as simple 
good practice?


But nothing beats good programming habits for cleaning up, i.e. "not 
littering" in the first place, as after the fact testing doesn't 
necessarily catch all cases where leaks can occur.  Analogous care at 
the programming stage applies to buffer overruns also as catching them 
after the fact is a dynamic trap shoot.  Same philosophy though.  As 
previously noted by another in this thread, the memleak may be load or 
data size dependent.  Or it may be dependent on some intermittent state 
of the underlying OS.  Some leaks can occur from structures accessed 
only via handles to the process and the OS doesn't necessarily release 
those structures when a process exits. But if the dev *always* 
explicitly makes the call to the system to release those structures via 
the handle then one can be far less concerned about the implications 
about what the system will or won't do if one doesn't


For what it is worth, from my view, I'm addressing a small percentage of 
developers out there who may have not considered the implications of 
some of this and how easy it can be avoided altogether with some simple 
practices at code time, rather than trying to mop up later in dynamic 
testing.  I have nothing but the highest respect and gratefulness for 
the sweat and care behind openssl and wouldn't be posting at all if I 
didn't, so thank you!



-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] request for TLBleed information / non-constant-time vulnerabilities

[Michael R. Hines via 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 stupid question, but what's the takeaway for a cloud
provider?

Well, in general, it's probably the commonplace that security is a process, not 
a product. There will always be new attacks of some sort.


Do we gather from these points that the entire set of timing
attacks will never really be known?

That's probably a safe assumption, particularly if "timing attacks" is defined 
broadly. (There was a famous timing attack against the TENEX logon mechanism back in the 
1970s; does that count?)

Even for computational timing attacks (like Kocher's) and microarchitectural 
timing attacks (like TLBleed), it would be impossible to prove you had the 
complete set unless the entire system was formally verified and the 
implementation could somehow be demonstrated to conform to the forrmal 
specification under all conditions.

In theory you can increase the noise on the channel to the point where it's no 
longer economical. Research on that goes back to at least the early 1990s. The 
problems, of course, are making sure you comprehensively inject noise into all 
the known channels, and finding users willing to pay the cost - increased noise 
means reduced efficiency. We see this trade-off in all sorts of side-channel 
attacks; in the cloud, for example, you have the various results showing 
security issues with memory deduplication.

For cloud computing, we've had at least a decade of research into this issue (see e.g. 
Ristenpart et al, "Hey, you, get off my cloud", published nine years ago so 
work presumably started no later than 2008). And it's still a problem, which means it's 
complicated and likely to be durable.


What does this confirm (or not confirm) about openssl's vulnerability
(or knowable status) to TLBleed?

Specifically? Not much. It goes more to the general principle that systems leak 
information as they do work. Ultimately it comes down to thermodynamics, and 
you never bet against thermodynamics.

--
Michael Wojcik
Distinguished Engineer, Micro Focus





--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Initialising OpenSSL more than once - how do we handle this?

[Salz, Rich via openssl-users]

  *   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

Re: [openssl-users] Initialising OpenSSL more than once - how do we handle this?

[Michael Wojcik]

> 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 be accurate, it was a couple of people saying that memory leaks *on 
> process exit* aren’t be a big deal.

And only singleton leaks, at that. But why sweat comprehension when there's an 
opportunity to be rude?

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 we're doing".

--
Michael Wojcik
Distinguished Engineer, Micro Focus





-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] openssl cms -decrypt failing due to malloc(3) failure

[Michael Wojcik]

> 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.

>if it's failing it's because it can't find that much contiguous virtual 
>address space, and mmap won't be able to
> find it either.

FWIW, SUS Issue 5 defines RLIMIT_AS as applying to both malloc and mmap, but 
RLIMIT_DATA as applying only to malloc. (That is, mmap'd pages do not count 
against the data limit.)

> If you're a 32-bit process, then malloc'ing or mmap'ing a 2GB object will be 
> difficult at best.

Agreed. And I'm not endorsing the mmap approach for this problem anyway - I'd 
use a streaming approach, so I'm not limited by address space.

--
Michael Wojcik
Distinguished Engineer, Micro Focus



-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Initialising OpenSSL more than once - how do we handle this?

[Marty G]

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 big deal.



Fair enough, but it is my understanding that some RTOSes do not 
necessarily dealloc all memory alloc'd by a proc on proc exit.  So why 
not just have a rule "don't litter" instead of having complicated rules 
of when it is "probably ok to litter"?  Exploits nearly always leverage 
something programmers didn't anticipate or happens in a layer they are 
relying on but not directly coding so it seems fairly clear that the 
best path is to reduce those unknowns by explicitly cleaning up.  Taking 
the time to track down a memory leak rarely results in merely fixing a 
memory leak; usually another programming misstep is also found in 
conjunction with the leak. Just my $0.02
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] openssl cms -decrypt failing due to malloc(3) failure

[Viktor Dukhovni]

> 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 
> space, and mmap won't be able to find it either.
> 
> If you're a 32-bit process, then malloc'ing or mmap'ing a 2GB object will be 
> difficult at best.

Getting out of the weeds, the core issue is that CMS message input processing
doesn't stream.  The entire CMS message has to fit into memory.  A different
data format is required for streaming large payloads.  The data would need
to be chunked with integrity protection and protection applied to each
chunk (packet) and appropriate sequence number integrity in place to
prevent reordering, insertion or deletion of chunks.

CMS works fine for small messages, and could even be used to construct
the integrity-protected chunks in a higher-level protocol.  CMS is
not appropriate for multi-gigabyte or terabyte, ... datasets.

-- 
Viktor.

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Initialising OpenSSL more than once - how do we handle this?

[Salz, Rich via openssl-users]

> 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: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Initialising OpenSSL more than once - how do we handle this?

[Marty G]

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 "important" leaks.


Maybe the test suite only caused the program to leak one buffer, but 
that doesn't tell you whether a real workload (or a malicious 
workload) will leak gigabytes.

--
Jordan Brown, Oracle Solaris


^^^ this

So much has changed in programming culture over the decades for me to be 
able to call it "engineering" any more.  Too much code equivalents of 
duct tape, chewing gum, and kite string holding things together out 
there and so many consider that normal and ok. I never thought I'd see 
the day that someone would have to defend not leaking memory in pivotal 
security code like openssl however
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] openssl cms -decrypt failing due to malloc(3) failure

[Jordan Brown]

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 can be /very/
> conveniently mmap(2)'ed into the process' address space, ignoring
> possible limits.
>
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 space, and mmap won't be able to find it either.

If you're a 32-bit process, then malloc'ing or mmap'ing a 2GB object
will be difficult at best.

-- 
Jordan Brown, Oracle Solaris

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Initialising OpenSSL more than once - how do we handle this?

[Jordan Brown]

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 Valgrind. In most
> environments that's pointless "optimization" and a waste of
> development resources.

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 "important" leaks.

Maybe the test suite only caused the program to leak one buffer, but
that doesn't tell you whether a real workload (or a malicious workload)
will leak gigabytes.

-- 
Jordan Brown, Oracle Solaris

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Initialising OpenSSL more than once - how do we handle this?

[Michael Wojcik]

> 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 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 Valgrind. In most environments that's pointless "optimization" and a 
waste of development resources.

--
Michael Wojcik
Distinguished Engineer, Micro Focus



-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Initialising OpenSSL more than once - how do we handle this?

[Viktor Dukhovni]

> 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, unloading and reloading on demand
risks crashes and memory leaks.  Others may disagree, but
I prefer to not assume that unloading is safe.

In OpenSSL 1.1.0, we try to do our best to make it safe,
but some one-time static allocations will still leak and
crash safety is likely platform-specific.

-- 
Viktor.

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] openssl cms -decrypt failing due to malloc(3) failure

[Michael Wojcik]

> 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
> mmap(2)'ed
> into the process' address space, ignoring possible limits.

Not portably, it can't. There are operating systems other than Linux and UNIX, 
and OpenSSL supports a number of them.

--
Michael Wojcik
Distinguished Engineer, Micro Focus


-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] openssl cms -decrypt failing due to malloc(3) failure

[Salz, Rich via openssl-users]

>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 list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Initialising OpenSSL more than once - how do we handle this?

[Graham Leggett]

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 OpenSSL is itself a 
> library.
> OpenSSL is now (and should ideally always have been) self-initializing.

What should be behaviour be in openssl < 1.1.0?

The scenario is as follows:

- httpd runs.
- httpd dynamically loads mod_ssl, apr_crypto_openssl, libpq, libldap, etc.
- mod_ssl, apr_crypto_openssl, libpq, libldap, etc in turn dynamically load 
openssl.
- At some point a graceful shutdown is attempted and mod_ssl, 
apr_crypto_openssl, libpq, libldap, etc are unloaded.
- …what next?

How should mod_ssl, apr_crypto_openssl, libpq, libldap, etc handle the 
unloading of openssl < 1.1.0?

Should they run the openssl init functions but not the teardown functions? (And 
just accept a leak).

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?

Regards,
Graham
—

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Intermediate cert file failure

[Tomas Mraz]

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:
> > > variable lookup failed for CA_default::default_md
> > > 3064446992:error:0E06D06C:configuration file
> > > routines:NCONF_get_string:no
> > > value:crypto/conf/conf_lib.c:275:group=CA_default name=default_md
> > 
> > Well ca(1) wants either an explicit "md" option or a default_md.
> > Perhaps it does not yet support ed25519.  You can sign directly
> > with "openssl x509", but first try
> > 
> > openssl ca -md null
> > or
> > openssl ca -md default
> > 
> > and see if either of those work.
> > 
> 
> -md null worked:
> 
> openssl ca -config $cadir/openssl-root.cnf -days 3650\
> -extensions v3_intermediate_ca -notext -md null\
> -in $dir/csr/intermediate.csr.$format\
> -out $dir/certs/intermediate.cert.pem
> 
> Can't open /root/ca/intermediate/index.txt.attr for reading, No such 
> file or directory
> 3064946704:error:02001002:system library:fopen:No such file or 
> directory:crypto/bio/bss_file.c:72:fopen('/root/ca/intermediate/index
> .txt.attr','r')
> 3064946704:error:2006D080:BIO routines:BIO_new_file:no such 
> file:crypto/bio/bss_file.c:79:
> Check that the request matches the signature
> Signature ok
> Certificate Details:
>  Serial Number:
>  ad:0f:52:5d:91:70:1a:d3
>  Validity
>  Not Before: Jul 27 16:41:03 2018 GMT
>  Not After : Jul 24 16:41:03 2028 GMT
>  Subject:
>  countryName   = US
>  stateOrProvinceName   = MI
>  organizationName  = HTT Consulting
>  commonName= Signing CA
>  X509v3 extensions:
>  X509v3 Subject Key Identifier:
> DB:5F:0C:00:54:DD:A6:EB:61:BD:79:13:0A:2D:EA:0A:19:82:E8:C5
>  X509v3 Authority Key Identifier:
> keyid:D6:1B:BA:96:44:EF:F1:07:59:35:A7:F2:77:5F:82:24:21:53:9A:9F
> 
>  X509v3 Basic Constraints: critical
>  CA:TRUE, pathlen:0
>  X509v3 Key Usage: critical
>  Certificate Sign, CRL Sign
>  X509v3 Subject Alternative Name:
>  email:postmas...@htt-consult.com
> Certificate is to be certified until Jul 24 16:41:03 2028 GMT (3650
> days)
> Sign the certificate? [y/n]:y
> 
> 
> 1 out of 1 certificate requests certified, commit? [y/n]y
> Write out database with 1 new entries
> Data Base Updated
> 
> There was no file index.txt.attr, but now there is:
> 
> # cat index.txt.attr
> unique_subject = yes
> 
> I don't remember this from my ecdsa work with 1.1.0
> 
> This issue with md is definitely and issue.  I can try -md null on
> the 
> self-signed root cert, but it seems that this should not even be 
> referenced for ed25519
> 
> But I got my intermediate cert, so on to the next step.
> 
> thanks for your help, Viktor.

Please open a Github issue for the default_md problem. It really
hampers the usability.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] openssl cms -decrypt failing due to malloc(3) failure

[Christian Böhme]

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 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 can be /very/ conveniently 
mmap(2)'ed
into the process' address space, ignoring possible limits.


Thanks,
Christian

-- 
*Christian Böhme*

Developer System Integration

CLOUD

*CLOUD & HEAT Technologies GmbH*
Königsbrücker Str. 96 (Halle 15) | 01099 Dresden
Tel: +49 351 479 3670 - 100
Fax: +49 351 479 3670 - 110
E-Mail: christian.boe...@cloudandheat.com 

Web: https://www.cloudandheat.com 

Handelsregister: Amtsgericht Dresden
Registernummer: HRB 30549
USt.-Ident.-Nr.: DE281093504
Geschäftsführer: Nicolas Röhrs




signature.asc
Description: OpenPGP digital signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users