Provide methods: EVP_PKEY_CTX_{g,s}et_rsa_oaep_md,
EVP_PKEY_CTX_{g,s}et0_rsa_oaep_label.
Based on Stephen Henson's patches for OpenSSL 1.1.0:
https://github.com/openssl/openssl/commit/271fef0ef39a1c0cb5233a5adf3ff8733abb375e
On Tue, Sep 03, 2019 at 02:03:52PM -0300, Martin Pieuchot wrote:
> On 18/08/19(Sun) 08:02, Alexandre Ratchov wrote:
> > Currently the block size calculations are broken by design: the driver
> > provides a round_blocksize() function which must retrun a valid block
> > size in *bytes*.
On 30.08., Stefan Sperling wrote:
> I would like to try this again: In iwm(4), process more than one frame
> per Rx interrupt, and enable monitor mode.
>
> Monitor mode triggers "unhandled fimware response" errors without multi-Rx
> support. We have seen these infamous errors in other contexts as
On 18/08/19(Sun) 08:02, Alexandre Ratchov wrote:
> Currently the block size calculations are broken by design: the driver
> provides a round_blocksize() function which must retrun a valid block
> size in *bytes*. Unfortunately, since the driver doesn't know if it's
> called for the play or for the
On Tue, 03 Sep 2019 17:11:22 +0200, Martijn van Duren wrote:
> I choose this value because I hit the maximum command length of the
> shell before. This way I'm somewhat confident that the shell doesn't
> do something weird with my command if we ever overflow it's internal
> buffer. So I based it
On Tue, Sep 03, 2019 at 08:51:09AM +0200, Antoine Jacoutot wrote:
> On Mon, Sep 02, 2019 at 08:58:01PM +0200, Hiltjo Posthuma wrote:
> > On Mon, Sep 02, 2019 at 12:07:59PM -0600, Theo de Raadt wrote:
> > > Hiltjo Posthuma wrote:
> > >
> > > > Hi,
> > > >
> > > > I have three questions regarding
Mark Kettenis:
> > This drops support for building the armv7 kernel with gcc and reduces
> > the difference to arm64.
>
> If we're keeping the gcc bits on other architectures, it makes sense
> to keep it here as well. Helps with diffability and someone might
> want to run the same tools for
Mark Kettenis wrote:
> > Date: Mon, 2 Sep 2019 17:32:04 +0200
> > From: Christian Weisgerber
> >
> > This drops support for building the armv7 kernel with gcc and reduces
> > the difference to arm64.
> >
> > I can't test this.
> >
> > OK? Or it can be rolled into somebody else's larger
On 9/3/19 4:30 PM, Todd C. Miller wrote:
> On Mon, 02 Sep 2019 21:15:23 +0200, Martijn van Duren wrote:
>
>> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/limits.h.html
>> {_POSIX_ARG_MAX}
>> Maximum length of argument to the exec functions including environment da
>> ta.
>>
> Date: Mon, 2 Sep 2019 17:32:04 +0200
> From: Christian Weisgerber
>
> This drops support for building the armv7 kernel with gcc and reduces
> the difference to arm64.
>
> I can't test this.
>
> OK? Or it can be rolled into somebody else's larger "remove gcc
> from armv7" diff.
If we're
On Mon, 02 Sep 2019 21:15:23 +0200, Martijn van Duren wrote:
> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/limits.h.html
> {_POSIX_ARG_MAX}
> Maximum length of argument to the exec functions including environment da
> ta.
> Value: 4 096
Note that this is the minimum value
Hello Masato-san,
Masato Asou wrote on Tue, Sep 03, 2019 at 02:39:11PM +0900:
> Does not run input command by vi editor with vi mode.
>
> I do the following:
>
> 1. set vi mode.
>$ echo "bind -v" > ~/.editrc
>
> 2. launch /usr/bin/ftp command.
>$ ftp
>
> 3. launch vi editor with ESC
On Mon, Sep 02, 2019 at 08:58:01PM +0200, Hiltjo Posthuma wrote:
> On Mon, Sep 02, 2019 at 12:07:59PM -0600, Theo de Raadt wrote:
> > Hiltjo Posthuma wrote:
> >
> > > Hi,
> > >
> > > I have three questions regarding a behaviour of syspatch(8) with mtree(8).
> > >
> > > 1. I noticed when
13 matches
Mail list logo
