The vote is as shown below.
OMC members should cast their vote here:
https://github.com/openssl/general-policies/pull/21
Mark
Topic: Accept the security policy as of
314ef25aa50e6f0c6a5b026251a06a1c4941e5a2
Proposed by: Mark Cox
Issue link: https://github.com/openssl/general-policies/pull/21
P
Topic: Update security prenotification policy to include MODERATE issues
Proposed by: Mark Cox
Issue link: https://github.com/openssl/general-policies/pull/20
Public: yes
Opened: 2022-05-11
Closed: -MM-DD
Accepted: yes/no (for: X, against: Y, abstained: Z, not voted: W)
Kurt [ ]
M
+, Mark J Cox wrote:
> > We have a script that runs daily and makes sure things needing action
> > for OTC/OMC are pinged if they get old. It also autocloses issues
> > where it was waiting for the reporter with no action, or waiting for
> > a
> > NDA for a signifi
(It looks like a bug in the script caused the dry run to actually
action a few of those changes already)
Mark
Mark
On Mon, 14 Mar 2022 at 10:29, Mark J Cox wrote:
>
> We have a script that runs daily and makes sure things needing action
> for OTC/OMC are pinged if they get old
We have a script that runs daily and makes sure things needing action
for OTC/OMC are pinged if they get old. It also autocloses issues
where it was waiting for the reporter with no action, or waiting for a
NDA for a significant amount of time.
Because 3.0 wasn't out, it ignored everything with th
0
On Tue, Feb 23, 2021 at 1:12 PM Tim Hudson wrote:
> 0
>
> Tim.
>
> On Tue, Feb 23, 2021 at 8:21 PM Tomas Mraz wrote:
>
>> topic: The RSA_SSLV23_PADDING and related functions should be
>> completely removed from OpenSSL 3.0 code.
>>
>> comment: The padding mode and the related functions (which
0
On Fri, Oct 9, 2020 at 1:02 PM Tomas Mraz wrote:
>
> topic: The PR #11359 (Allow to continue with further checks on
> UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for 1.1.1 branch
> As the change is borderline on bug fix/behaviour change OTC needs
> to decide whether it is acceptable for 1.1
+1
On Fri, Oct 9, 2020 at 1:03 PM Tomas Mraz wrote:
>
> +1
>
> On Fri, 2020-10-09 at 15:00 +0300, Nicola Tuveri wrote:
> > topic: Hold online weekly OTC meetings starting on Tuesday 2020-10-13
> >and until 3.0 beta1 is released, in lieu of the weekly
> > "developer
> >meetings".
>
+1
On Wed, Sep 30, 2020 at 2:57 PM 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, against:
Didn't see any response one way or the other so I'll create a 'ignore
ci failure' label, change the bot logic to deal with it, and go
through the stale things in the failed CI state.
Mark
On Mon, Sep 7, 2020 at 11:15 AM Mark J Cox wrote:
>
> So when we have a PR
I just spotted it via twitter, https://raccoon-attack.com/
Mark
On Wed, Sep 9, 2020 at 2:08 PM Dmitry Belyavsky wrote:
>
> Could you please let me know when it is available?
>
> On Wed, Sep 9, 2020 at 3:51 PM Mark J Cox wrote:
>>
>> They should be releasing thei
They should be releasing their paper very soon (today).
Regards, Mark
On Wed, Sep 9, 2020 at 1:45 PM Dmitry Belyavsky wrote:
>
> Is the description of the attack publicly available?
>
> On Wed, Sep 9, 2020 at 3:39 PM OpenSSL wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>>
>>
So when we have a PR in a state where any CI is marked as failing I
lump them into a single "failed CI" state. The stale (over 30 day old
untouched) ones are shown below. But most of them (if not all) are
not actually CI failures. Aside from fixing the CI, one solution
would be a label "Ignore C
During June I updated the stale PR script to start to ping reporters where
issues were in the "changes requested" state. I corrected some issues that
were incorrectly in this state where changes had been supplied. I also got the
script to close the issues still "waiting for CLA" that had had no r
topic: Change some words by accepting PR#12089
Proposed by Mark Cox
Public: yes
opened: 2020-06-25
Rich Salz mailed me about the issues that were in the "waiting for
reporter" state in my summary noting that some of them shouldn't be in
that state. I investigated just now and made some changes to my
script, so if you are a reviewer or reporter you may get some extra
pings today as things moved
In April I started a script to ping stale PRs that were in certain
states. The script has also been collecting statistics (trending and
snapshot). I intend to post this monthly and after a few months with
trends and commentary.
PRs that have not had any updates in the last 30 days and are not WI
FYI The OMC voted last week to update the security policy extending
prenotifications[1] and we've just released a blog explaining this
change[2]
[1] https://github.com/openssl/web/pull/176/files
[2] https://www.openssl.org/blog/blog/2020/05/12/security-prenotifications/
Regards, Mark
On Fri, May 1, 2020 at 3:30 PM Dmitry Belyavsky wrote:
..
> And I also got an idea that ping comment leaves PRs out of this statistics :)
Thanks! The script is designed to ignore the automated pings that it
creates itself so they themselves don't reset the dates and
artificially stop things bein
Last month I started a script to ping stale PRs that were in certain
states. The script has also been collecting statistics (trending and
snapshot). I intend to post this monthly and after a few months with
trends and commentary.
PRs that have not had any updates in the last 30 days and are not
Earlier this month I started a script to ping stale PRs that were in
certain states. The script has also been collecting statistics
(trending and snapshot). I intend to post this monthly and after a
few months with trends and commentary.
PRs that have not had any updates in the last 30 days and
> But recently you started to
> add various prefixes like "Automated Ping:" and now "openssl-machine:". I'd
> prefer if the messages
> were consistently without a prefix, because they only distract from the gist
> of the message IMHO,
> in particular consistency junkies like me.
openssl-machine:
We have over 50 PRs that are in the state where they are held
requiring a CLA, and stale (over 30 days since any comments). My
intention is to have my script ping all these PRs with a comment like
this:
openssl-machine: This PR has the label "hold: cla required" and is
stale: it has not been upda
On Thu, Feb 27, 2020 at 9:31 AM Matthias St. Pierre
wrote:
> Because after all, the shape of the logo is an
> essential part of the OpenSSL 'trade mark'.
Although the current website logo as of January 2020 was used as the
specimen to show our use of the trademark at renewal time, our
official tr
If you are wondering what the strange automated pings are, I'm just
experimenting looking at stale issues in various states and what we should
do about them. (The tool is clever enough to ignore its own comments
etc). I'm just running the tool manually at the moment. The idea is it
will ping is
Correct, it has no way to know if something has been put into ready to
merge deliberately despite it failing checks etc so it won't mess with
removing the label.
Mark
On Wed, Feb 12, 2020 at 10:39 AM Dr. Matthias St. Pierre
wrote:
>
> > check. It will not move to 'ready to merge' state automati
I thought about it some more and Kurt is right. Something shouldn't
be in "Ready to Merge" unless it's actually ready to merge. For
example 10993. This PR shouldn't be ever automatically moved to ready
to merge because it failed CI. A human has determined it is ready to
merge and applied the la
> Does it also check that the CI says that everything is OK?
Do we want it to? I assumed that Approval: done was not being applied
unless tests past (but looking that's not always the case). Can we
assume that something in "approval: ready to merge" but that failed CI
won't get merged? Otherwise
n if it is done
differently or not used in the future should a better way present
itself.
Mark
On Sun, Feb 9, 2020 at 12:19 AM Matt Caswell wrote:
>
>
>
> On 08/02/2020 15:56, Mark J Cox wrote:
> > I've currently got a cron job running every hour that looks at open PR
> &g
;
> As the reviewers are expected to commit the PRs, could you also add the
> reviewers' names as a part of the notification?
>
> On Sat, Feb 8, 2020 at 6:56 PM Mark J Cox wrote:
>>
>> I've currently got a cron job running every hour that looks at open PR
>> r
I've currently got a cron job running every hour that looks at open PR
requests against github openssl repo and does various actions. So if
you were wondering why I was altering labels and making comments at
4am, now you know. No doubt we'll use some tool user for this in the
future.
So right no
We're planning a face to face two day committers meeting in October 2019.
If you're an OpenSSL committer you should have received an email from me
with the dates and locations we are considering to get your likely
availability to help us choose the best location. If you didn't get the
email le
Changes to policies require an OMC vote which I've called to approve an
update to the security policy. This was as discussed at the face to face
and the details and diff are at https://github.com/openssl/web/pull/96
topic: Update security policy as per https://github.com/openssl/
done.
On Mon, Aug 13, 2018 at 5:11 PM, Matt Caswell wrote:
> Please could someone freeze the repo for me?
>
> $ ssh openssl-...@git.openssl.org freeze openssl matt
>
> Thanks
>
> Matt
> ___
> openssl-project mailing list
> openssl-project@openssl.org
>
Just as a FYI in case anyone is interested in an OpenSSL-related
submission (if you want to do something joint with me, I'm interested
and local lol).
> Conference: Open Source Summit Europe
> Location: Edinburgh
> Dates: October 22 – 24
>
> Deadline for speaking submissions: July 1
https://event
unlike the text versions
we had to create, and are instead created using a script[4] from the
XML format[3] we use to populate the OpenSSL site.
Step by step Instructions for release managers are (temporarily)
included in cvepool.txt file in the private repo.
Mark J Cox
[1] https://github.com/
36 matches
Mail list logo