On Thu, Aug 02, 2018 at 01:53:42PM +0200, Christian Böhme wrote:
> > In any case, the OpenSSL apps are a convenience and a set of samples.
>
> My original impression was that those tools represented some kind of reference
> implementation of the libraries. Clearly, I was wrong ;-)
Well,
Hello,
On 01.08.2018 14:49, Michael Wojcik wrote:
>> On 30.07.2018 20:12, Michael Wojcik wrote:
>>
>>> 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.)
>>
On 01/08/2018 15:42, Viktor Dukhovni wrote:
On Aug 1, 2018, at 9:31 AM, Michael Wojcik
wrote:
CMS with an AEAD mode (such as AES128-GCM) ought to avoid the
integrity-protection issue for the encrypted content, but not for the other
parts of the message, I assume. (I'm no CMS expert so I
> On Aug 1, 2018, at 9:31 AM, Michael Wojcik
> wrote:
>
> CMS with an AEAD mode (such as AES128-GCM) ought to avoid the
> integrity-protection issue for the encrypted content, but not for the other
> parts of the message, I assume. (I'm no CMS expert so I may be missing
> something
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of Viktor Dukhovni
> Sent: Wednesday, August 01, 2018 06:56
>
> On Tue, Jul 31, 2018 at 06:14:18PM +0200, Jakob Bohm wrote:
>
> > Actually, the CMS format itself is clearly designed for streamed decoding.
>
> It is not,
On Tue, Jul 31, 2018 at 06:14:18PM +0200, Jakob Bohm wrote:
> > 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.
>
> Actually, the CMS
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of Christian Böhme
> Sent: Tuesday, July 31, 2018 10:16
>
> On 30.07.2018 20:12, Michael Wojcik wrote:
>
> > FWIW, SUS Issue 5 defines RLIMIT_AS as applying to both malloc and mmap,
> > but RLIMIT_DATA as
> > applying
On 30.07.2018 20:12, Michael Wojcik wrote:
>> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
>> Jordan Brown
>> Sent: Monday, July 30, 2018 10:46
[…]
> FWIW, SUS Issue 5 defines RLIMIT_AS as applying to both malloc and mmap, but
> RLIMIT_DATA as
> applying only to
On 30/07/2018 20:07, Viktor Dukhovni wrote:
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
> 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 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
> 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
>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 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
>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.
--
openssl-users mailing list
To unsubscribe:
Hello all,
Assume that we have
$ uname -srvmpio
Linux 4.4.0-109-generic #132-Ubuntu SMP Tue Jan 9 19:52:39 UTC 2018 x86_64
x86_64 x86_64 GNU/Linux
$ openssl version
OpenSSL 1.0.2g 1 Mar 2016
$ printenv SHELL
/bin/bash
$ ulimit -a
core file size (blocks, -c) 0
data seg size
17 matches
Mail list logo
