Yep, frankly the current behavior of the app in regards to failing
-check/-pubcheck does not make that much sense and really looks more
like a bug than anything else.
If the user does not care about the failure of the check and want to
proceed with other actions, nothing stops them from just not
I have closed the vote now.
The vote was accepted, although with a very narrow margin.
accepted: yes (for: 3, against: 2, abstained: 5, not voted: 1)
Tomas
On Fri, 2020-10-09 at 14:02 +0200, Tomas Mraz wrote:
> topic: The PR #11359 (Allow to continue with further che
I wonder if something like adding a new entropy source on an existing platform
especially on some that currently don't have adequate ones would be covered by
this.
Tomáš
19. 10. 2020 18:29, 18:29, Matt Caswell napsal/a:
>
>
>On 19/10/2020 15:14, Matt Caswell wrote:
>> LTS+ releases may
+1
On Thu, 2020-10-08 at 15:47 +0100, Matt Caswell wrote:
> topic: The following items are required prerequisites for the first
> beta
> release:
> 1) EVP is the recommended API, it must be feature-complete compared
> with
> the functionality available using lower-level APIs.
>- Anything
On Thu, 2020-10-08 at 09:47 +0100, Matt Caswell wrote:
>
> On 07/10/2020 19:07, Kurt Roeckx wrote:
> > On Wed, Oct 07, 2020 at 12:35:28PM +0100, Matt Caswell wrote:
> > > The following items are required prerequisites for the first beta
> > > release:
> > [...]
> > > * Address 3.0beta1
+1 to that. There is a reason why almost all the major projects
switched over to doing time based releases instead of feature
completeness based ones.
Of course the 3.0 release is kind of special because we are defining a
completely new API - the providers API - with the intention to have it
On Wed, 2020-10-07 at 12:35 +0100, Matt Caswell wrote:
> I had an action from the OTC meeting today to raise a vote on the OTC
> list of technical items still to be done. Here is my proposed vote
> text.
> There will be a subsequent vote on the "beta readiness checklist"
> which
> is a separate
On Mon, 2020-10-05 at 10:00 +0100, Matt Caswell wrote:
>
> On 04/10/2020 15:22, Kurt Roeckx wrote:
> > On Wed, Sep 23, 2020 at 08:51:28PM +0200, Kurt Roeckx wrote:
> > > Hi,
> > >
> > > I would like to have a system so that we can tag issues as
> > > important. But I think they fall in a few
+1
On Wed, 2020-09-30 at 13:57 +, Dr. Matthias St. Pierre wrote:
> The following vote has been proposed and voted on at the vF2F today:
>
> topic: OTC meeting will be called for next Tuesday
>
> It has been closed immediately by Tim, the verdict is
>
> accepted: yes (for: 7,
Hello,
unfortunately no, 1.1.1g is neither API nor ABI compatible with 1.0.2f.
You cannot directly replace 1.0.2f with 1.1.1g. The applications have
to support 1.1.1 release and be recompiled against it to work with it.
Regards,
Tomas Mraz
On Tue, 2020-09-22 at 14:08 +, Kapil Awate wrote
On Fri, 2020-09-18 at 16:24 +0100, Matt Caswell wrote:
>
> 1 PR which is in a state of "its unclear what we do with this":
> [WIP] Rename some XXX_ex() related methods to XXX_with_libctx()
> https://github.com/openssl/openssl/pull/12701
> With no agreement on a naming convention its unclear if
On Fri, 2020-09-18 at 09:26 +0200, Richard Levitte wrote:
> On Thu, 17 Sep 2020 15:57:52 +0200,
> Tomas Mraz wrote:
> > I do not think the milestone should include nice-to-have items.
>
> Another view is that beta 1 is feature freeze. If those nice to have
> items are
On Thu, 2020-09-17 at 13:48 +0100, Matt Caswell wrote:
> There's been quite a number of PRs added to the 3.0 beta 1 milestone.
>
> Within the PRs there are a couple of bug fixes:
>
> https://github.com/openssl/openssl/pull/12884
> https://github.com/openssl/openssl/pull/12874
>
> IMO these
On Wed, 2020-09-09 at 22:29 +1000, Dr Paul Dale wrote:
> > On 9 Sep 2020, at 9:38 pm, Tomas Mraz wrote:
> >
> > We could even provide a convenience thread local stack of lib
> > contexts
> > so the caller would not have to keep the old value but would just
&g
On Wed, 2020-09-09 at 11:41 +0200, Richard Levitte wrote:
>
> Regarding the library context, when viewed as a global state, it
> makes
> sense to have it as a first argument where it's being passed, if at
> all. The question is, where should we actually pass it? We have a
> few different
+1 for the removal
Tomáš
27. 7. 2020 4:58, 4:58, SHANE LONTIS napsal/a:
>
>i.e. Choose option (1)
>
>> On 27 Jul 2020, at 11:14 am, SHANE LONTIS
>wrote:
>>
>> If this is not going to break 99% of users + it improves the
>interface + the replacement to achieve the same is a few lines of code
It was backported to Fedora and RHEL openssl packages. But of course that's our
problem and is not a blocker for the rename.
On the other hand KDFs and MACs being a class of algorithms similarly to
ciphers and digests gives some argument why to keep the EVP prefix.
Tomáš
Tomáš
24. 7.
On Thu, 2020-07-23 at 10:35 +0300, Dmitry Belyavsky wrote:
> Hello,
>
> I go on my vacation from July 24 to August 5. On vacation, my
> internet access is very limited.
> If you have smth urgent, please let me know via direct email.
>
Same here. I will be on vacation from July 24th to August
On Thu, 2020-06-25 at 14:49 +, Dr. Matthias St. Pierre wrote:
> Since already a few backporting requests to 1.1.1 have accumulated
> which are controversial
> or not allowed for an LTS release, would it make sense to consider
> creating a new 1.1.2 STS
> branch which could then receive such
On Sun, 2020-06-21 at 14:34 -0700, Benjamin Kaduk wrote:
> Hi Tim,
>
> On Sat, Jun 20, 2020 at 10:11:04AM +1000, Tim Hudson wrote:
> > I suggest everyone takes a read through
> > https://en.wikipedia.org/wiki/Long-term_support as to what LTS is
> > actually
> > meant to be focused on.
>
> You
On Fri, 2020-06-19 at 01:48 +1000, Tim Hudson wrote:
> We have a convention that we mostly follow. Adding new stuff with
> variations in the convention offers no benefit without also adjusting
> the rest of the API. Inconsistencies really do not assist any
> developer.
>
> Where APIs have been
Apparently the travis jobs are not getting started anymore for some
reason.
It happened to me on the GitHub linux-pam project and the solution (or
workaround) was to migrate the project to the travis-ci.com.
I just did it by following the instructions in this document:
On Wed, 2020-05-27 at 14:16 +, Dr. Matthias St. Pierre wrote:
> > IMO it seems appropriate to have an OMC vote on this topic (or
> > should it
> > be OTC?). Possible wording:
>
> Personally, I would prefer if technical questions would by default be
> discussed (and voted on)
> by the OTC,
On Wed, 2020-05-27 at 12:14 +0100, Matt Caswell wrote:
> PR 10787 proposed to reduce the number of security bits for MD5 and
> SHA1
> in TLS (master branch only, i.e. OpenSSL 3.0):
>
> https://github.com/openssl/openssl/pull/10787
>
> This would have the impact of meaning that TLS < 1.2 would
On Fri, 2020-05-08 at 12:09 +0200, Kurt Roeckx wrote:
> On Thu, May 07, 2020 at 02:31:24PM +0200, Tomas Mraz wrote:
> > On Thu, 2020-05-07 at 12:47 +0100, Matt Caswell wrote:
> > > On 07/05/2020 12:22, Kurt Roeckx wrote:
> > > > So I think we need at least to
On Thu, 2020-05-07 at 15:45 +0200, Kurt Roeckx wrote:
> On Thu, May 07, 2020 at 03:15:22PM +0200, Tomas Mraz wrote:
> > Actually the coincidence is that the errno is set to 0 on EOF. So
> > yes,
> > we should explicitly clear the errno on EOF so any leftover value
> > f
On Thu, 2020-05-07 at 14:53 +0200, Kurt Roeckx wrote:
> On Thu, May 07, 2020 at 01:46:05PM +0200, Tomas Mraz wrote:
> > From application developer side of view for protocols that do not
> > depend on SSL detecting the truncation I think inventing a
> > different
> >
On Thu, 2020-05-07 at 12:47 +0100, Matt Caswell wrote:
>
> On 07/05/2020 12:22, Kurt Roeckx wrote:
> > So I think we need at least to agree on:
> > - Do we want an option that makes the unexpected EOF either a fatal
> > error or a non-fatal error?
> > - Which error should we return?
>
> This
On Thu, 2020-05-07 at 13:22 +0200, Kurt Roeckx wrote:
> Hi,
>
> We introduced a change in the 1.1.1e release that changed how we
> handled an unexpected EOF. This broke various software which
> resulted in the release of 1.1.1f that reverted that change.
> In master we still have the 1.1.1e
On Thu, 2020-05-07 at 09:24 +0100, Matt Caswell wrote:
> PR11589 makes a change to the public API function
> `SSL_set_record_padding_callback` to change its return type from void
> to
> int:
>
> https://github.com/openssl/openssl/pull/11589
>
> This is technically an API break - but it doesn't
That we do not run CI explicitly before such cherry picks does not mean
that there is no CI run at all. The CI is triggered when the cherry-
picked commit is merged. If we were checking the status of the 1.1.1
branch CI runs periodically (with a bot sending e-mails about failures
to
On Thu, 2020-03-26 at 14:14 +, Matt Caswell wrote:
> The EOF issue (https://github.com/openssl/openssl/issues/11378) has
> resulted in us reverting the original EOF change in the 1.1.1 branch
> (https://github.com/openssl/openssl/pull/11400).
>
> Given that this seems to have broken quite a
On Wed, 2020-03-04 at 10:18 +, Matt Caswell wrote:
>
> On 04/03/2020 08:15, Tomas Mraz wrote:
> > The current implementation in the PR - unconditionally returning
> > error
> > - is completely useless. It would make some (not much) sense if we
> > aimed for ABI
On Wed, 2020-03-04 at 13:47 +1000, SHANE LONTIS wrote:
> FIPS_mode() and FIPS_mode_set() are functions that were used by the
> old FOM.
>
> In OpenSSL_111 they were stripped down to do almost nothing
> i.e:-
>
> int FIPS_mode(void)
> {
> /* This version of the library does not
On Thu, 2020-02-27 at 11:28 +0100, Matthias St. Pierre wrote:
> Thank you for the clarification, Mark.
>
> So this means we have some artistic freedom in choosing the logo?
>
> Personally, I'm not sure whether we really should aim at restoring
> the historic logo. IMHO this ornate font with 3D
On Thu, 2020-02-27 at 10:31 +0100, Matthias St. Pierre wrote:
>
> The openssl.svg was chosen to match the current logo at
>
> https://www.openssl.org/
>
> as close as possible. According to the style sheet, the font of the
> logo
> is HelveticaNeue-Light.
>
>
Could you, please, send me the .ai file? I'll try converting it. Is the
font freely available?
Tomas
On Thu, 2020-02-27 at 14:17 +0800, Paul Yang wrote:
> The logo could be changed to the 'correct-font' version -as the one
> printed on the stickers I brought to Nuremberg
>
> I have an '.ai’
On Fri, 2020-02-14 at 16:17 +, Salz, Rich wrote:
> I think we should delay the deprecation of engine stuff to 4.0.
> Personally I don't have sense of stability of provider API.
>
> I share this concern. This is the first release of the provider
> infrastructure, and while it will be known
On Fri, 2020-02-14 at 12:30 +1000, Dr Paul Dale wrote:
> There is some pushback against the deprecations going on in various
> PRs.
>
> The plan has always been to deprecate engines in 3.0 and removing
> support for them 5+ years later. Originally, the path was to have
> included an engine
I can only add +1 to what Matthias suggests. Although I know the
meaning of the FIPS_MODE define, for a newcomer it is obviously not
clear what the define really means.
Tomas
On Tue, 2020-01-21 at 13:31 +0100, Matthias St. Pierre wrote:
> On 21.01.20 10:36, Richard Levitte wrote:
> > I think
On Fri, 2020-01-17 at 10:34 +, Matt Caswell wrote:
>
> On 17/01/2020 06:31, Dr Paul Dale wrote:
> > 1. Leave them public and unchanged — that is, don’t deprecate
> > these two
> > functions yet.
> > 2. Deprecate them and add KDFs to replace them.
> > 3. Deprecate them, leave them alone
On Fri, 2020-01-17 at 16:31 +1000, Dr Paul Dale wrote:
> In the deprecation efforts for 3.0, I’ve hit something in the DES
> code that I’d appreciate input on.
>
> There are two functions (DES_crypt and DES_fcrypt) which implement
> the old crypt(3) password algorithm. Once these are deprecated,
The "always check for NULL pointers" approach does not avoid
catastrophical errors in applications. For example let's say an
application code encrypts some plaintext in-place and sends it out as
encrypted. Let's say we check for the NULL EVP_CIPHER_CTX in
EVP_CipherUpdate() but the app does not
On Thu, 2019-11-28 at 11:19 -0800, Benjamin Kaduk wrote:
> On Wed, Nov 27, 2019 at 10:38:41AM +0100, Richard Levitte wrote:
> > Depending on who you're asking, you get different responses.
> >
> > The topic is: should we check pointers coming from applications
> > before
> > using them or not?
>
On Mon, 2019-09-02 at 08:38 +0200, Richard Levitte wrote:
> The dispute in PR https://github.com/openssl/openssl/pull/7853 has
> made it quote obvious that we have some very different ideas on when
> and why we should or shouldn't deprecate stuff.
>
> What does deprecation mean? Essentially,
On Mon, 2019-07-15 at 16:25 +0200, Richard Levitte wrote:
> On Mon, 15 Jul 2019 16:15:01 +0200,
> Tomas Mraz wrote:
> > So saying this is "just recompliation and configuration change" is
> > at least somewhat oversimplified.
> >
> > But I am OK with t
On Mon, 2019-07-15 at 14:48 +0100, Matt Caswell wrote:
>
> On 15/07/2019 14:43, Tomas Mraz wrote:
> > On Mon, 2019-07-15 at 14:19 +0100, Matt Caswell wrote:
> > > On 15/07/2019 13:58, Tomas Mraz wrote:
> > > >
> > > IMO this is a major
On Mon, 2019-07-15 at 14:19 +0100, Matt Caswell wrote:
>
> On 15/07/2019 13:58, Tomas Mraz wrote:
> > Hi everyone,
> >
> > if the Subject was already fully discussed and thought through then
> > please disregard this but otherwise I'd like this e-mail to be a
>
Hi everyone,
if the Subject was already fully discussed and thought through then
please disregard this but otherwise I'd like this e-mail to be a
starting point for discussion.
I suppose the current intention is to make the legacy provider as opt-
in only by either application explicitly loading
On Fri, 2019-06-07 at 10:18 +0200, Tomas Mraz wrote:
> On Fri, 2019-06-07 at 18:03 +1000, Dr Paul Dale wrote:
> >
> > Viktor replied:
> >
> > > I just want to make sure we don't lock ourselves in to a single
> > > potentially clumsy solution in the
On Thu, 2019-05-23 at 17:17 +0200, Richard Levitte wrote:
> On Thu, 23 May 2019 16:25:07 +0200,
> Salz, Rich wrote:
> > I understand that OpenSSL is changing things so that, by mechanism
> > (and maybe by policy although
> > it’s not published yet), two members of the same company cannot
> >
101 - 151 of 151 matches
Mail list logo
