Re: OTC VOTE: The PR #11359 (Allow to continue with further checks on UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for 1.1.1 branch

2020-10-12 Thread Mark J Cox
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 branch.
> Proposed by Tomas Mraz
> Public: yes
> opened: 2020-10-09
> closed: 2020-mm-dd
> accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)
>
>   Matt   [  ]
>   Mark   [  ]
>   Pauli  [  ]
>   Viktor [  ]
>   Tim[  ]
>   Richard[  ]
>   Shane  [  ]
>   Tomas  [+1]
>   Kurt   [  ]
>   Matthias   [  ]
>   Nicola [  ]
>
> --
> 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.]
>
>


Re: VOTE: Weekly OTC meetings until 3.0 beta1 is released

2020-10-10 Thread Mark J Cox
+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".
> > Proposed by Nicola Tuveri
> > Public: yes
> > opened: 2020-10-09
> > closed: 2020-mm-dd
> > accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)
> >
> >   Matt   [  ]
> >   Mark   [  ]
> >   Pauli  [  ]
> >   Viktor [  ]
> >   Tim[  ]
> >   Richard[  ]
> >   Shane  [  ]
> >   Tomas  [  ]
> >   Kurt   [  ]
> >   Matthias   [  ]
> >   Nicola [+1]
> --
> 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.]
>
>


Re: VOTE: OTC meeting will be called for next Tuesday

2020-09-30 Thread Mark J Cox
+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: 0, abstained: 0, not voted: 4)
>
> (Note: the OTC meeting will be held in place of the weekly OpenSSL 3.0 
> Planning
> meeting next Tuesday (2020-10-06) at 08:00 UTC. Pauli will send out a separate
> invitation to the OTC list.)
>
> Matthias
>
> 
> topic: OTC meeting will be called for next Tuesday (2020-10-06)
> Proposed by Matthias St. Pierre
> Public: yes
> opened: 2020-09-30
> closed: 2020-09-30
> accepted:  yes  (for: 7, against: 0, abstained: 0, not voted: 4)
>
>   Matt   [+1]
>   Mark   [  ]
>   Pauli  [+1]
>   Viktor [  ]
>   Tim[+1]
>   Richard[+1]
>   Shane  [+1]
>   Tomas  [  ]
>   Kurt   [  ]
>   Matthias   [+1]
>   Nicola [+1]
>
>


Re: When "failed CI" isn't a blocker

2020-09-21 Thread Mark J Cox
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 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 CI failure" which can be manually set by a
> committer who reviews the fail and it's harmless, then I could have
> the bot ignore failed CI when that label is present.  (And perhaps the
> bot also resets the label if the CI gets restarted due to changes).
> That would help have things in the right state bucket and can be acted
> on/reminded properly.
>
> Mark
>
> at Sep7: failed CI  ( 19 issues, median  276  days)
> 11464  days:37 [* mjc: travis timeout on one combination, could ignore]
> 11327 reviewed:commented days:177 [* mjc: same]
> 11288 branch: master, reviewed:commented days:180 [* mjc: same]
> 11257 branch: 1.1.1, branch: master, reviewed:approved days:178 [*
> mjc: same, ..]
> 11151  days:189
> 10797 branch: master, reviewed:commented days:150
> 10556  days:276
> 10465  days:293
> 9926  days:355
> 9603  days:355
> 9155 reviewed:commented days:229
> 8955 branch: 1.1.1, branch: master, reviewed:dismissed days:304
> 8115 reviewed:commented days:177
> 7921 reviewed:commented days:548
> 7914 reviewed:approved days:607
> 7380 reviewed:commented days:695
> 7051 milestone:Assessed, reviewed:commented days:744
> 4992 milestone:Assessed, reviewed:commented days:317
> 4338 milestone:Assessed,  days:153


Re: OpenSSL Security Advisory

2020-09-09 Thread Mark J Cox
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 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
>> >>
>> >> OpenSSL Security Advisory [09 September 2020]
>> >> =
>> >>
>> >> Raccoon Attack (CVE-2020-1968)
>> >> ==
>> >>
>> >> Severity: Low
>> >>
>> >> The Raccoon attack exploits a flaw in the TLS specification which can 
>> >> lead to
>> >> an attacker being able to compute the pre-master secret in connections 
>> >> which
>> >> have used a Diffie-Hellman (DH) based ciphersuite. In such a case this 
>> >> would
>> >> result in the attacker being able to eavesdrop on all encrypted 
>> >> communications
>> >> sent over that TLS connection. The attack can only be exploited if an
>> >> implementation re-uses a DH secret across multiple TLS connections. Note 
>> >> that
>> >> this issue only impacts DH ciphersuites and not ECDH ciphersuites.
>> >>
>> >> OpenSSL 1.1.1 is not vulnerable to this issue: it never reuses a DH 
>> >> secret and
>> >> does not implement any "static" DH ciphersuites.
>> >>
>> >> OpenSSL 1.0.2f and above will only reuse a DH secret if a "static" DH
>> >> ciphersuite is used. These static "DH" ciphersuites are ones that start 
>> >> with the
>> >> text "DH-" (for example "DH-RSA-AES256-SHA"). The standard IANA names for 
>> >> these
>> >> ciphersuites all start with "TLS_DH_" but excludes those that start with
>> >> "TLS_DH_anon_".
>> >>
>> >> OpenSSL 1.0.2e and below would reuse the DH secret across multiple TLS
>> >> connections in server processes unless the SSL_OP_SINGLE_DH_USE option was
>> >> explicitly configured. Therefore all ciphersuites that use DH in servers
>> >> (including ephemeral DH) are vulnerable in these versions. In OpenSSL 
>> >> 1.0.2f
>> >> SSL_OP_SINGLE_DH_USE was made the default and it could not be turned off 
>> >> as a
>> >> response to CVE-2016-0701.
>> >>
>> >> Since the vulnerability lies in the TLS specification, fixing the affected
>> >> ciphersuites is not viable. For this reason 1.0.2w moves the affected
>> >> ciphersuites into the "weak-ssl-ciphers" list. Support for the
>> >> "weak-ssl-ciphers" is not compiled in by default. This is unlikely to 
>> >> cause
>> >> interoperability problems in most cases since use of these ciphersuites 
>> >> is rare.
>> >> Support for the "weak-ssl-ciphers" can be added back by configuring 
>> >> OpenSSL at
>> >> compile time with the "enable-weak-ssl-ciphers" option. This is not 
>> >> recommended.
>> >>
>> >> OpenSSL 1.0.2 is out of support and no longer receiving public updates.
>> >>
>> >> Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2w.  If
>> >> upgrading is not viable then users of OpenSSL 1.0.2v or below should 
>> >> ensure
>> >> that affected ciphersuites are disabled through runtime configuration. 
>> >> Also
>> >> note that the affected ciphersuites are only available on the server side 
>> >> if a
>> >> DH certificate has been configured. These certificates are very rarely 
>> >> used and
>> >> for this reason this issue has been classified as LOW severity.
>> >>
>> >> This issue was found by Robert Merget, Marcus Brinkmann, Nimrod Aviram 
>> >> and Juraj
>> >> Somorovsky and reported to OpenSSL on 28th May 2020 under embargo in 
>> >> order to
>> >> allow co-ordinated disclosure with other implementations.
>> >>
>> >> Note
>> >> 

Re: OpenSSL Security Advisory

2020-09-09 Thread Mark J Cox
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
>>
>> OpenSSL Security Advisory [09 September 2020]
>> =
>>
>> Raccoon Attack (CVE-2020-1968)
>> ==
>>
>> Severity: Low
>>
>> The Raccoon attack exploits a flaw in the TLS specification which can lead to
>> an attacker being able to compute the pre-master secret in connections which
>> have used a Diffie-Hellman (DH) based ciphersuite. In such a case this would
>> result in the attacker being able to eavesdrop on all encrypted 
>> communications
>> sent over that TLS connection. The attack can only be exploited if an
>> implementation re-uses a DH secret across multiple TLS connections. Note that
>> this issue only impacts DH ciphersuites and not ECDH ciphersuites.
>>
>> OpenSSL 1.1.1 is not vulnerable to this issue: it never reuses a DH secret 
>> and
>> does not implement any "static" DH ciphersuites.
>>
>> OpenSSL 1.0.2f and above will only reuse a DH secret if a "static" DH
>> ciphersuite is used. These static "DH" ciphersuites are ones that start with 
>> the
>> text "DH-" (for example "DH-RSA-AES256-SHA"). The standard IANA names for 
>> these
>> ciphersuites all start with "TLS_DH_" but excludes those that start with
>> "TLS_DH_anon_".
>>
>> OpenSSL 1.0.2e and below would reuse the DH secret across multiple TLS
>> connections in server processes unless the SSL_OP_SINGLE_DH_USE option was
>> explicitly configured. Therefore all ciphersuites that use DH in servers
>> (including ephemeral DH) are vulnerable in these versions. In OpenSSL 1.0.2f
>> SSL_OP_SINGLE_DH_USE was made the default and it could not be turned off as a
>> response to CVE-2016-0701.
>>
>> Since the vulnerability lies in the TLS specification, fixing the affected
>> ciphersuites is not viable. For this reason 1.0.2w moves the affected
>> ciphersuites into the "weak-ssl-ciphers" list. Support for the
>> "weak-ssl-ciphers" is not compiled in by default. This is unlikely to cause
>> interoperability problems in most cases since use of these ciphersuites is 
>> rare.
>> Support for the "weak-ssl-ciphers" can be added back by configuring OpenSSL 
>> at
>> compile time with the "enable-weak-ssl-ciphers" option. This is not 
>> recommended.
>>
>> OpenSSL 1.0.2 is out of support and no longer receiving public updates.
>>
>> Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2w.  If
>> upgrading is not viable then users of OpenSSL 1.0.2v or below should ensure
>> that affected ciphersuites are disabled through runtime configuration. Also
>> note that the affected ciphersuites are only available on the server side if 
>> a
>> DH certificate has been configured. These certificates are very rarely used 
>> and
>> for this reason this issue has been classified as LOW severity.
>>
>> This issue was found by Robert Merget, Marcus Brinkmann, Nimrod Aviram and 
>> Juraj
>> Somorovsky and reported to OpenSSL on 28th May 2020 under embargo in order to
>> allow co-ordinated disclosure with other implementations.
>>
>> Note
>> 
>>
>> OpenSSL 1.0.2 is out of support and no longer receiving public updates. 
>> Extended
>> support is available for premium support customers:
>> https://www.openssl.org/support/contracts.html
>>
>> OpenSSL 1.1.0 is out of support and no longer receiving updates of any kind.
>> The impact of this issue on OpenSSL 1.1.0 has not been analysed.
>>
>> Users of these versions should upgrade to OpenSSL 1.1.1.
>>
>> References
>> ==
>>
>> URL for this Security Advisory:
>> https://www.openssl.org/news/secadv/20200909.txt
>>
>> Note: the online version of the advisory may be updated with additional 
>> details
>> over time.
>>
>> For details of OpenSSL severity classifications please see:
>> https://www.openssl.org/policies/secpolicy.html
>> -BEGIN PGP SIGNATURE-
>>
>> iQIzBAEBCgAdFiEEeVOsH7w9yLOykjk+1enkP3357owFAl9YzBsACgkQ1enkP335
>> 7oyIxg/9FWuca3/s/lY6g6a5VTPIekZMOLRUnDyzS3YePQu/sEd1w81mKoTqU+6F
>> KQmliGqdRDk+KN8HDVd14kcLBukto8UKmkp9FpB5J4d2KK1I/Fg/DofJs6xUQYKb
>> 5rHRLB3DDoyHEBzEEIjcqYTTThXW9ZSByVK9SKpC78IRM/B2dfd0+j4hIB/kDC/E
>> G+wieFzexHQVdleVYT/VaJ6qS8AwvohBbt8h7yK0P6v/4vEm0spDbUmjWJBVUlUu
>> QZyELjj8XZR3YFxt3axSuJg3JSGYlaMzkt2+DVq4qEzeJLIydLK9J8p6RNwPhsJk
>> Rx0ez8P4N+5O7XmA0nHv3HyompdMgHlvykj8Ks4lNHVS02KKLi1jDtmOxl3Fm/hb
>> ZNOmjn7lulV1342pw4rWL3Nge3x0s0Q5zgBCm1mqLzzu/V1ksx8FJwGA1w2cH280
>> dU9VedkC2wvFQije8pFrWH9l6N9Bh41DIEOnlBl0AL7IrbPdO6yMcD6vpR7hWjr3
>> fx4hNJSAGzJ3i/NXlSj4eR/47zkjfJyEc8Drc2QgewyqXFrK20X/LOj8MqJlc+ry
>> pXZseh+XC8WaYDMV1ltrKvE2Ld9/0f3Ydc04AcDeu5SXPJG79ogzVnchZok7+XCj
>> RT+a3/ES45+CTfL5v27t5QJxJcxg4siLVsILfi0rIUv0IYgH2fU=
>> =U7OO
>> -END PGP SIGNATURE-
>
>
>
> --
> SY, Dmitry Belyavsky


When "failed CI" isn't a blocker

2020-09-07 Thread Mark J Cox
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 CI failure" which can be manually set by a
committer who reviews the fail and it's harmless, then I could have
the bot ignore failed CI when that label is present.  (And perhaps the
bot also resets the label if the CI gets restarted due to changes).
That would help have things in the right state bucket and can be acted
on/reminded properly.

Mark

at Sep7: failed CI  ( 19 issues, median  276  days)
11464  days:37 [* mjc: travis timeout on one combination, could ignore]
11327 reviewed:commented days:177 [* mjc: same]
11288 branch: master, reviewed:commented days:180 [* mjc: same]
11257 branch: 1.1.1, branch: master, reviewed:approved days:178 [*
mjc: same, ..]
11151  days:189
10797 branch: master, reviewed:commented days:150
10556  days:276
10465  days:293
9926  days:355
9603  days:355
9155 reviewed:commented days:229
8955 branch: 1.1.1, branch: master, reviewed:dismissed days:304
8115 reviewed:commented days:177
7921 reviewed:commented days:548
7914 reviewed:approved days:607
7380 reviewed:commented days:695
7051 milestone:Assessed, reviewed:commented days:744
4992 milestone:Assessed, reviewed:commented days:317
4338 milestone:Assessed,  days:153


Stale PR stats @Jul 2020

2020-06-30 Thread Mark J Cox
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 response for
several months of automated reminders.  Finally, there were a few issues in
"waiting for review" state that were given reviews or otherwise updated.

PRs that have not had any updates in the last 30 days and are not WIP:

all  ( 132 issues, median  248  days) of which:

 failed CI  ( 22 issues, median  183 days)
 deferred after 1.1.1  ( 46 issues)
 cla required  ( 0 issues)
 waiting for reporter  ( 8 issues, median  255 days)
 waiting for review  ( 0 issues)
 waiting for OMC  ( 1 issue)
 waiting for OTC  ( 4 issues, median  44 days)
 all other  ( 51 issues, median  239 days)

So, ignoring deferred issues too you could summarise this as:

 Stale PRs waiting for us to do something: 27 (last months: 36, 27, 29)
 Stale PRs waiting for the reporter to do something: 8 (last months: 34, 34, 37)
 Stale PRs with unclear next action: 51 (last months: 48, 46, 42)
 Total Stale PRs: 86 (last months: 118, 107, 108)

There really shouldn't be anything "waiting for OMC/OTC/review" that
is over 30 days; many of these did get a decision and the state just
isn't updated.

Over time I hope we can triage the "all other" PRs with labels so we
know what the next action is on each one.

Details:

 waiting for reporter:
10590 reviewed:changes_requested days:175
10063 branch: master, reviewed:changes_requested days:35
9461 reviewed:changes_requested days:335
9427 reviewed:changes_requested days:342
8962 reviewed:changes_requested days:104
8706 branch: master, reviewed:changes_requested days:36
7961 reviewed:changes_requested days:540
7432 reviewed:changes_requested days:619

 waiting for OMC:
10195 branch: master, hold: need omc decision, reviewed:commented days:232

 waiting for OTC:
11757 hold: cla required, hold: need otc decision,  days:48
8916 approval: review pending, branch: 1.1.1, branch: master,
hold: need otc decision, reviewed:changes_requested days:41
8300 approval: otc review pending, branch: 1.1.1, branch: master,
hold: need otc decision, reviewed:review pending days:144
8024 approval: otc review pending, branch: master,
reviewed:commented days:33

 all other:
11779 cla: trivial,  days:48
11744  days:62
11712 branch: master, reviewed:commented days:57
11679  days:116
11481 branch: 1.1.1, branch: master,  days:81
11421  days:70
11398 approval: done, branch: master, reviewed:approved days:95
11359  days:75
11341  days:73
11312  days:107
11260 reviewed:commented days:115
11248 reviewed:commented days:33
6  days:77
5  days:116
11082 branch: master,  days:67
11057  days:140
10884  days:162
10818  days:168
10570 reviewed:commented days:184
10541  days:199
10338 reviewed:commented days:239
10320 branch: 1.1.1, branch: master, reviewed:commented days:230
10298  days:243
10268  days:245
9655  days:217
9554  days:326
9421 branch: 1.1.1, branch: master, reviewed:approved days:181
9223 branch: master, reviewed:commented days:143
9206  days:374
9051 reviewed:commented days:237
8956  days:396
8920  days:273
8908  days:411
8862  days:390
8835  days:430
8743 branch: master,  days:441
8668  days:452
8455  days:454
8420  days:455
8333  days:490
8309 branch: master, reviewed:commented days:376
7688  days:576
7615  days:580
7454 reviewed:commented days:531
7274 reviewed:approved days:382
7225 reviewed:commented days:647
6518 milestone:Assessed, reviewed:approved days:741
6448 milestone:Assessed,  days:248
6219 milestone:Assessed, reviewed:approved days:779
4487 milestone:Assessed,  days:718
4486 milestone:Assessed,  days:718


OMC Vote: Change some words by accepting PR#12089

2020-06-26 Thread Mark J Cox
topic: Change some words by accepting PR#12089
Proposed by Mark Cox
Public: yes
opened: 2020-06-25


Re: Stale PR stats @Jun01

2020-06-02 Thread Mark J Cox
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 to the right state.

The script looked at the github timeline 'reviewed' events, however
those events only happen when changes are requested or the review is
approved or rejected.  So if a reporter does an update and re-requests
a review, it still shows up for the script in state
"changes_requested" which isn't true.  So now the script also looks at
"review_requested" events, and a "review_requested" will change the
state from "changes_requested".

When looking through the list one by one I spotted quite a few PRs
which had changes_requested but where the reporter had made some
changes or commented about the changes but had not re-requested a
review.  I manually did that re-request.

I'll also add a OpenSSL Machine comment to stale "changes_requested"
state issues to remind the reporter to do that action (and to be sure
to re-request a review once they have done so).

So here was the state before:

>  waiting for reporter  ( 16 issues, median  299.5  days)
>
> 11530 branch: 1.1.1, branch: master, cla: trivial,
> reviewed:changes_requested days:46
> 11514 reviewed:changes_requested days:50
> 11310 reviewed:changes_requested days:74
> 10724 reviewed:changes_requested days:37
> 10590 reviewed:changes_requested days:146
> 9575 reviewed:changes_requested days:293
> 9461 reviewed:changes_requested days:306
> 9427 reviewed:changes_requested days:313
> 9243 reviewed:changes_requested days:315
> 9240 reviewed:changes_requested days:340
> 8992 reviewed:changes_requested days:257
> 8962 reviewed:changes_requested days:75
> 8730 reviewed:changes_requested days:354
> 8674 reviewed:changes_requested days:409
> 7961 reviewed:changes_requested days:511
> 7432 reviewed:changes_requested days:590
>
>  waiting for review  ( 2 issues, median  40.5  days)
>
> 11526 approval: review pending, branch: 1.1.1, branch: master,
> reviewed:approved days:32
> 11278 approval: review pending, branch: master, reviewed:commented days:49

And now it is:

 waiting for reporter  ( 9 issues, median  308  days)

11530 branch: 1.1.1, branch: master, cla: trivial,
reviewed:changes_requested days:48
10590 reviewed:changes_requested days:148
9575 reviewed:changes_requested days:294
9461 reviewed:changes_requested days:308
9427 reviewed:changes_requested days:315
8962 reviewed:changes_requested days:76
8674 reviewed:changes_requested days:411
7961 reviewed:changes_requested days:513
7432 reviewed:changes_requested days:592

 waiting for review  ( 8 issues, median  51.5  days)

11526 approval: review pending, branch: 1.1.1, branch: master,
reviewed:approved days:34
11514 reviewed:review pending days:52
11278 approval: review pending, branch: master, reviewed:commented days:51
10724 reviewed:review pending days:38
10632 reviewed:review pending days:35
8992 reviewed:review pending days:258
8730 reviewed:review pending days:356
6725 milestone:Assessed, reviewed:review pending days:363


Stale PR stats @Jun01

2020-06-01 Thread Mark J Cox
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 WIP:

all  ( 158 issues, median  219  days) of which:

 failed CI  ( 28 issues, median  114.0  days)
 deferred after 1.1.1  ( 40 issues, median  219.0  days)
 cla required  ( 18 issues, median  442.0  days)
 waiting for reporter  ( 16 issues, median  299.5  days)
 waiting for review  ( 2 issues, median  40.5  days)
 waiting for OMC  ( 3 issues, median  83  days)
 waiting for OTC  ( 3 issues, median  55  days)
 all other  ( 48 issues, median  215.0  days)

So, ignoring deferred issues too you could summarise this as:

 Stale PRs waiting for us to do something: 36 (last months: 27,29)
 Stale PRs waiting for the reporter to do something: 34 (last months: 34,37)
 Stale PRs with unclear next action: 48 (last months: 46,42)

There really shouldn't be anything "waiting for OMC/OTC/review" that
is over 30 days; many of these did get a decision and the state just
isn't updated.

Over time I hope we can triage the "all other" PRs with labels so we
know what the next action is on each one.

Details:

 waiting for reporter  ( 16 issues, median  299.5  days)

11530 branch: 1.1.1, branch: master, cla: trivial,
reviewed:changes_requested days:46
11514 reviewed:changes_requested days:50
11310 reviewed:changes_requested days:74
10724 reviewed:changes_requested days:37
10590 reviewed:changes_requested days:146
9575 reviewed:changes_requested days:293
9461 reviewed:changes_requested days:306
9427 reviewed:changes_requested days:313
9243 reviewed:changes_requested days:315
9240 reviewed:changes_requested days:340
8992 reviewed:changes_requested days:257
8962 reviewed:changes_requested days:75
8730 reviewed:changes_requested days:354
8674 reviewed:changes_requested days:409
7961 reviewed:changes_requested days:511
7432 reviewed:changes_requested days:590

 waiting for OMC  ( 3 issues, median  83  days)

10786 approval: done, branch: 1.1.1, branch: master, hold: need
omc decision, reviewed:approved days:83
10195 branch: master, hold: need omc decision, reviewed:commented days:203
5909 hold: need omc decision, milestone:Assessed,
reviewed:changes_requested days:34

 waiting for OTC  ( 3 issues, median  55  days)

9654 approval: otc review pending, branch: master, triaged:
feature, reviewed:changes_requested days:55
9537 approval: otc review pending, hold: cla required,
reviewed:commented days:47
8300 approval: otc review pending, branch: 1.1.1, branch: master,
hold: need otc decision, reviewed:approved days:115

 waiting for review  ( 2 issues, median  40.5  days)

11526 approval: review pending, branch: 1.1.1, branch: master,
reviewed:approved days:32
11278 approval: review pending, branch: master, reviewed:commented days:49

 all other  ( 48 issues, median  215.0  days)

11679  days:87
11545  days:47
11421  days:41
11398 approval: done, branch: master, reviewed:approved days:66
11359  days:46
11341  days:44
11312  days:78
11277 resolved: not a bug,  days:81
11260 reviewed:commented days:86
6  days:48
5  days:87
11057  days:111
10884  days:133
10818  days:139
10570 reviewed:commented days:155
10541  days:170
10338 reviewed:commented days:210
10320 branch: 1.1.1, branch: master, reviewed:commented days:201
10298  days:214
10268  days:216
9655  days:188
9554  days:297
9444 branch: master, reviewed:commented days:41
9421 branch: 1.1.1, branch: master, reviewed:approved days:152
9223 branch: master, reviewed:commented days:114
9206  days:345
9051 reviewed:commented days:208
8956  days:367
8920  days:244
8908  days:382
8862  days:361
8835  days:401
8743 branch: master,  days:412
8668  days:423
8455  days:425
8420  days:426
8333  days:461
8309 branch: master, reviewed:commented days:347
7688  days:547
7615  days:551
7454 reviewed:commented days:502
7274 reviewed:approved days:353
7225 reviewed:commented days:618
6725 milestone:Assessed, reviewed:approved days:361
6518 milestone:Assessed, reviewed:approved days:712
6448 milestone:Assessed,  days:219
6219 milestone:Assessed, reviewed:approved days:750
4487 milestone:Assessed,  days:689


Prenotification policy change

2020-05-12 Thread Mark J Cox
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


Re: Stale PR stats @May01

2020-05-01 Thread Mark J Cox
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 being stale.  Instead they will hopefully
nudge folks into taking some action that will actually stop the PRs
being stale :))

Mark


Stale PR stats @May01

2020-05-01 Thread Mark J Cox
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 WIP:

all  ( 148 issues, median  188  days) of which:

  failed CI  ( 23 issues, median  175  days)
  deferred after 1.1.1  ( 41 issues, median  188  days)
  cla required  ( 19 issues, median  422  days)
  waiting for reporter  ( 15 issues, median  275  days)
  waiting for review  ( 1 issues, median  38  days)
  waiting for OMC  ( 2 issues, median  112.0  days)
  waiting for OTC  ( 1 issues, median  84  days)
  all other  ( 46 issues, median  239.5  days)

So, ignoring deferred issues too you could summarise this as:

Stale PRs waiting for us to do something: 27 (last months: 29)
Stale PRs waiting for the reporter to do something: 34 (last months: 37)
Stale PRs with unclear next action: 46 (last months: 42)

Over time I hope we can triage the "all other" PRs with labels so we
know what the next action is on each one.

Details:

failed CI  ( 23 issues, median  175  days)

11349 branch: master, reviewed:commented days:43
11327 reviewed:commented days:48
11288 branch: master, reviewed:commented days:51
11257 branch: 1.1.1, branch: master, reviewed:approved days:49
11195 branch: 1.1.1, branch: master, reviewed:commented days:38
11151  days:60
10626  days:66
10556  days:147
10465  days:164
9926  days:226
9603  days:226
9155 reviewed:commented days:100
8955 branch: 1.1.1, branch: master, reviewed:dismissed days:175
8687 reviewed:commented days:210
8389  days:415
8115 reviewed:commented days:48
7921 reviewed:commented days:419
7914 reviewed:approved days:478
7380 reviewed:commented days:566
7051 milestone:Assessed, reviewed:commented days:615
6074 milestone:Assessed, reviewed:commented days:658
4992 milestone:Assessed, reviewed:commented days:188
4486 milestone:Assessed,  days:658

waiting for reporter  ( 15 issues, median  275  days)

11310 reviewed:changes_requested days:43
10887 branch: master, reviewed:changes_requested days:37
10590 reviewed:changes_requested days:115
9677 branch: master, reviewed:changes_requested days:32
9575 reviewed:changes_requested days:262
9461 reviewed:changes_requested days:275
9427 reviewed:changes_requested days:282
9243 reviewed:changes_requested days:284
9240 reviewed:changes_requested days:309
8992 reviewed:changes_requested days:226
8962 reviewed:changes_requested days:44
8730 reviewed:changes_requested days:323
8674 reviewed:changes_requested days:378
7961 reviewed:changes_requested days:480
7432 reviewed:changes_requested days:559

waiting for OMC  ( 2 issues, median  112.0  days)

10786 approval: done, branch: 1.1.1, branch: master, hold: need
omc decision, reviewed:approved days:52
10195 branch: master, hold: need omc decision, reviewed:commented days:172

waiting for OTC  ( 1 issues, median  84  days)

8300 approval: otc review pending, branch: 1.1.1, branch: master,
hold: need otc decision, reviewed:approved days:84

waiting for review  ( 1 issues, median  38  days)

10587 approval: review pending, branch: 1.1.1, branch: master,
reviewed:commented days:38

all other  ( 46 issues, median  239.5  days)

11398 approval: done, branch: master, reviewed:approved days:35
11312  days:47
11277 resolved: not a bug,  days:50
11260 reviewed:commented days:55
11154  days:66
5  days:56
11057  days:80
10884  days:102
10818  days:108
10570 reviewed:commented days:124
10541  days:139
10338 reviewed:commented days:179
10320 branch: 1.1.1, branch: master, reviewed:commented days:170
10298  days:183
10268  days:185
10037  days:147
9655  days:157
9554  days:266
9421 branch: 1.1.1, branch: master, reviewed:approved days:121
9223 branch: master, reviewed:commented days:83
9206  days:314
9051 reviewed:commented days:177
8956  days:336
8920  days:213
8908  days:351
8862  days:330
8835  days:370
8743 branch: master,  days:381
8668  days:392
8455  days:394
8420  days:395
8333  days:430
8309 branch: master, reviewed:commented days:316
8024 reviewed:commented days:81
7688  days:516
7615  days:520
7454 reviewed:commented days:471
7274 reviewed:approved days:322
7225 reviewed:commented days:587
6725 milestone:Assessed, reviewed:approved days:330
6518 milestone:Assessed, reviewed:approved days:681
6516 branch: 1.1.1, branch: master, milestone:Assessed,  days:681
6448 milestone:Assessed,  days:188
6219 milestone:Assessed, reviewed:approved days:719
5427 branch: master, milestone:Assessed, reviewed:commented days:481
4487 milestone:Assessed,  

Stale PR stats @Apr01

2020-04-01 Thread Mark J Cox
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 are not WIP:

 all  ( 153 issues, median  158  days) of which:

 failed CI  ( 21 issues, median  158  days)
 deferred after 1.1.1  ( 45 issues, median  158  days)
 cla required  ( 24 issues, median  325.0  days)
 waiting for reporter  ( 13 issues, median  252  days)
 waiting for review  ( 3 issues, median  44  days)
 waiting for OMC  ( 3 issues, median  142  days)
 waiting for OTC  ( 2 issues, median  43.5  days)
 all other  ( 42 issues, median  289.0  days)

So, ignoring deferred issues too you could summarise this as:

Stale PRs waiting for us to do something: 29 (27%)
Stale PRs waiting for the reporter to do something: 37 (34%)
Stale PRs with unclear next action: 42 (39%)

Over time I hope we can triage the "all other" PRs with labels so we
know what the next action is on each one.

Detail:

failed CI  ( 21 issues, median  158  days)

11151  days:30
11136 reviewed:commented days:36
6  days:42
10626  days:36
10556  days:117
10465  days:134
10344 branch: master,  days:149
9926  days:196
9603  days:196
9155 reviewed:commented days:70
8955 branch: 1.1.1, branch: master, reviewed:dismissed days:145
8687 reviewed:commented days:180
8389  days:385
8024 reviewed:commented days:51
7921 reviewed:commented days:389
7914 reviewed:approved days:448
7380 reviewed:commented days:536
7051 milestone:Assessed, reviewed:commented days:585
6074 milestone:Assessed, reviewed:commented days:628
4992 milestone:Assessed, reviewed:commented days:158
4486 milestone:Assessed,  days:628

 waiting for reporter  ( 13 issues, median  252  days)

10724 reviewed:changes_requested days:76
10590 reviewed:changes_requested days:85
9575 reviewed:changes_requested days:232
9461 reviewed:changes_requested days:245
9427 reviewed:changes_requested days:252
9243 reviewed:changes_requested days:254
9240 reviewed:changes_requested days:279
8992 reviewed:changes_requested days:196
8730 reviewed:changes_requested days:293
8674 reviewed:changes_requested days:348
7961 reviewed:changes_requested days:450
7432 reviewed:changes_requested days:529
2986 milestone:Assessed, reviewed:changes_requested days:158

 waiting for review  ( 3 issues, median  44  days)

10563 approval: review pending, branch: 1.1.1, branch: master,
reviewed:approved days:44
10063 approval: review pending, reviewed:approved days:32
8916 approval: review pending, branch: 1.1.1, branch: master,
reviewed:approved days:125

 waiting for OMC  ( 3 issues, median  142  days)

10195 branch: master, hold: need omc decision, reviewed:commented days:142
7285 hold: need omc decision, reviewed:changes_requested days:35
5909 hold: need omc decision, milestone:Assessed,
reviewed:changes_requested days:643

 waiting for OTC  ( 2 issues, median  43.5  days)

9654 approval: otc review pending, branch: master, triaged:
feature, reviewed:changes_requested days:33
8300 approval: otc review pending, branch: 1.1.1, branch: master,
hold: need otc decision, reviewed:approved days:54

 all other  ( 42 issues, median  289.0  days)

11154  days:36
11057  days:50
10884  days:72
10818  days:78
10570 reviewed:commented days:94
10541  days:109
10338 reviewed:commented days:149
10320 branch: 1.1.1, branch: master, reviewed:commented days:140
10298  days:153
10268  days:155
10037  days:117
9655  days:127
9554  days:236
9421 branch: 1.1.1, branch: master, reviewed:approved days:91
9223 branch: master, reviewed:commented days:53
9206  days:284
9051 reviewed:commented days:147
8956  days:306
8920  days:183
8908  days:321
8862  days:300
8835  days:340
8743 branch: master,  days:351
8668  days:362
8455  days:364
8420  days:365
8333  days:400
8309 branch: master, reviewed:commented days:286
7688  days:486
7615  days:490
7485 branch: 1.1.1, branch: master, reviewed:commented days:516
7454 reviewed:commented days:441
7274 reviewed:approved days:292
7225 reviewed:commented days:557
6725 milestone:Assessed, reviewed:approved days:300
6518 milestone:Assessed, reviewed:approved days:651
6516 branch: 1.1.1, branch: master, milestone:Assessed,  days:651
6448 milestone:Assessed,  days:158
6219 milestone:Assessed, reviewed:approved days:689
5860 branch: 1.1.1, branch: master, milestone:Assessed,
reviewed:commented days:222
5427 branch: master, milestone:Assessed, reviewed:commented days:451
4487 milestone:Assessed,  days:628


Re: My next step in handling stale PRs

2020-03-03 Thread Mark J Cox
> 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: was just my reminder prefix to run this as
openssl-machine and not me, but it's a fair point on the automated
ping and future consistency.  People may even pay more attention if
they don't realise it was a python script hassling them.

Thanks, Mark


My next step in handling stale PRs

2020-03-03 Thread Mark J Cox
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 updated in X days.   Note that this PR may be
automatically closed in the future if no CLA is provided.  For CLA
help see https://www.openssl.org/policies/cla.html

In another month we can decide it we want to autoclose them (note that
any comment, label change, etc, made to the PR after the above will
reset the timer and take it out of the list of possible ones to close)

I'll run it later in the week to give people a chance to voice any
comments or concerns.

Mark


Re: OpenSSL Logo (was: New GitHub Project Landing Page)

2020-02-27 Thread Mark J Cox
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 trademark registration is a standard character mark:  i.e.
"The mark consists of standard characters without claim to any
particular font style, size, or color.".

Regards, Mark


Fwd: [openssl/openssl] A nonce does not have a minimum length (#5909)

2020-02-25 Thread Mark J Cox
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 issues where appropriate and do reports and generally end up
being a way we can monitor to make sure our project is healthy.

For example, nothing should be in a state waiting for an OMC decision for
more than a few weeks - it should be decided upon and moved to whatever
state the outcome of the decision is.  We had three of these (and looking
at them they all should just be in a different state).  For every issue it
ought to be very clear what the next action is (I'm a big fan of GTD
(Getting Things Done) process!)

So, right now, we have 82 PR's that have not been touched in the last 180
days.  I picked 180 just for an example because it creates a shorter list
and in practice I imagine 30 days will be the reports we do:

So of the 82:

* deferred after 1.1.1  ( 5 issues)
  - this is a valid state for stale PRs.  An item falls here if it's set to
the milestone for 1.1.1 or it's marked branch 1.1.1 and not master

* waiting for OMC  ( 2 issues)
  - as discussed above, we'll just comment them to ping the OMC

* waiting for OTC/waiting for review ( 0 issues)
  - similar to OMC, we'll just autocomment them to ping the OTC/committers

* cla required  ( 22 issues)
  - if something has been waiting for a CLA for 30 days or more we probably
ought to ping it a couple of times, but then reject the PR as it's unlikely
we'll get a CLA if none have been supplied after a couple of pings and a
couple of months.

* failed CI  ( 14 issues)
  - if it's not in any of the states above but it failed CI it ends up
here.  Some of these might be known false positives, so no action other
than interesting to monitor?  Maybe we need some label for "it failed CI
but that's expected and not a blocker"?  that way there's an action on the
PR creator to "get this in a state where CI passes" and we could auto
comment anything that's failed CI and not been touched for a month (and
perhaps even close it as rejected the next time).

* all the rest ( 39 issues)
  - most of these have no labels or milestones.  Some have
milestone:Assessed (but not sure how that helps).  Some have branch
labels.  This is just the backlog.

Mark

-- Forwarded message -
From: openssl-machine 
Date: Tue, Feb 25, 2020 at 9:00 AM
Subject: Re: [openssl/openssl] A nonce does not have a minimum length
(#5909)
To: openssl/openssl 

Automated Ping: This issue is in a state where it requires action by
@openssl/omc  but the last
update was 607 days ago

—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
,
or unsubscribe

.


Re: Github PR label automation

2020-02-12 Thread Mark J Cox
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 automatically
> > unless (or until) all CI passes.  (I'll do a PR for the tool with that
> > change shortly).
>
> If the does not automatically remove the "ready to merge" label, but only
> refrains from setting it automatically, that's a good compromise I can live 
> with.
>
> Matthias
>


Re: Github PR label automation

2020-02-12 Thread Mark J Cox
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 label.  So "ready to merge" really ought to mean
that.  So I've updated the live script that's running to do that
check.  It will not move to 'ready to merge' state automatically
unless (or until) all CI passes.  (I'll do a PR for the tool with that
change shortly).

Mark

On Wed, Feb 12, 2020 at 8:49 AM Dr. Matthias St. Pierre
 wrote:
>
> > > 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 I could add a CI check on the move to
> > "ready to merge".
>
> It does not check and I don't think it should attempt to do it. The only task 
> of
> this script should be to automatically promote the [approval: done] state to
> [approval: ready to merge] after the grace period has expired, because humans
> tend to forget that. Anything beyond that, in particular an attempt to judge
> whether the approval is valid or not, and whether a CI failure can be ignored 
> or
> not, should be left to humans.
>
> Matthias
>


Re: Github PR label automation

2020-02-12 Thread Mark J Cox
> 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 I could add a CI check on the move to
"ready to merge".

Mark


Re: Github PR label automation

2020-02-09 Thread Mark J Cox
Okay, I'll leave things as they are with those issues and just add the
addition of notification on urgent labels.

As to the earlier question form the thread as why this isn't a github
automation: the actual reason I was writing the script was to get some
on-demand statistics for my own interest and it just turned out this
was something that bugged me that I could use the same framework for
(I did a trivial review and thought how annoying it would be to have
to manually set a reminder myself to do a future action).  I was a
pretty trivial (few hours) script, so I have no concern 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
> > 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 now here's what it does:
> >
> > Every hour it looks at open PRs that are labelled "approval: done".
> > If 24 hours has elapsed since that label was assigned and if there
> > have been no comments made to the PR since the label was assigned then
> > it is automatically moved to "approval: ready to merge" with a comment
> > added to trigger notifications.  So if you want to stop something
> > going to "ready to merge" just add any comment to the PR.
> >
> > I'm thinking of using this script also to 1) collect interesting stats
> > and 2) do some other actions.  So if there's some automation you'd
> > like to see just add an enhancement issue against the openssl/tools
> > repo.
> >
> > 1 Matt already asked for committer notification trigger for anything
> > labelled Urgent.
> >
> > 2 If there were comments made after "approval: done" then I think we
> > really ought to drop the "approval: done" label as the comments likely
> > invalidated the approval.  So I'll likely add that next week (if
> > "approval: done" label and has comments since that label then remove
> > the label and add a comment 'please review if this is really approval:
> > done'.  If the approval: done label gets set again then after 24 hours
> > the existing automation will trigger.  #10786 is a good example of
> > this.
>
> I'm less sure about this. I think there are probably many examples where
> this is not the case. E.g. a quick review found these recent cases:
>
> https://github.com/openssl/openssl/pull/11003
>
> https://github.com/openssl/openssl/pull/11015
>
> https://github.com/openssl/openssl/pull/10992
>
> https://github.com/openssl/openssl/pull/10991
>
> https://github.com/openssl/openssl/pull/10990
>
> https://github.com/openssl/openssl/pull/10989
>
> I would be more minded to think that if a comment invalidates an
> "approval done" then the committer should explicitly decide to do that.
>
> Matt


Re: Github PR label automation

2020-02-08 Thread Mark J Cox
Thanks Dmitry; I hope that the comment triggers notifications to the
creator without mentioning them?  (let me know if you get something
changed labels that doesn't)   Mark

On Sat, Feb 8, 2020 at 4:57 PM Dmitry Belyavsky  wrote:
>
> Dear Mark,
>
> Thank you for a nice job!
>
> 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
>> 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 now here's what it does:
>>
>> Every hour it looks at open PRs that are labelled "approval: done".
>> If 24 hours has elapsed since that label was assigned and if there
>> have been no comments made to the PR since the label was assigned then
>> it is automatically moved to "approval: ready to merge" with a comment
>> added to trigger notifications.  So if you want to stop something
>> going to "ready to merge" just add any comment to the PR.
>>
>> I'm thinking of using this script also to 1) collect interesting stats
>> and 2) do some other actions.  So if there's some automation you'd
>> like to see just add an enhancement issue against the openssl/tools
>> repo.
>>
>> 1 Matt already asked for committer notification trigger for anything
>> labelled Urgent.
>>
>> 2 If there were comments made after "approval: done" then I think we
>> really ought to drop the "approval: done" label as the comments likely
>> invalidated the approval.  So I'll likely add that next week (if
>> "approval: done" label and has comments since that label then remove
>> the label and add a comment 'please review if this is really approval:
>> done'.  If the approval: done label gets set again then after 24 hours
>> the existing automation will trigger.  #10786 is a good example of
>> this.
>>
>> Mark
>
>
>
> --
> SY, Dmitry Belyavsky


Github PR label automation

2020-02-08 Thread Mark J Cox
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 now here's what it does:

Every hour it looks at open PRs that are labelled "approval: done".
If 24 hours has elapsed since that label was assigned and if there
have been no comments made to the PR since the label was assigned then
it is automatically moved to "approval: ready to merge" with a comment
added to trigger notifications.  So if you want to stop something
going to "ready to merge" just add any comment to the PR.

I'm thinking of using this script also to 1) collect interesting stats
and 2) do some other actions.  So if there's some automation you'd
like to see just add an enhancement issue against the openssl/tools
repo.

1 Matt already asked for committer notification trigger for anything
labelled Urgent.

2 If there were comments made after "approval: done" then I think we
really ought to drop the "approval: done" label as the comments likely
invalidated the approval.  So I'll likely add that next week (if
"approval: done" label and has comments since that label then remove
the label and add a comment 'please review if this is really approval:
done'.  If the approval: done label gets set again then after 24 hours
the existing automation will trigger.  #10786 is a good example of
this.

Mark


Planning a face to face committers meeting

2019-08-06 Thread Mark J Cox
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 let me know off list.

Regards, Mark


[openssl-project] Vote to update the security policy

2018-11-29 Thread Mark J Cox
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/web/pull/96
comment: as discussed f2f
Proposed by Mark Cox
Public: yes
opened: 2018-11-29
closed: -mm-dd
ONE WEEK VOTE


___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Please freeze the repo

2018-08-13 Thread Mark J Cox
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
> https://mta.openssl.org/mailman/listinfo/openssl-project
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


[openssl-project] Open Source Summit Europe

2018-06-19 Thread Mark J Cox
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://events.linuxfoundation.org/events/open-source-summit-europe-2018/

Mark
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

[openssl-project] Mitre GIT CVE pilot, vulnerability JSON files

2018-02-12 Thread Mark J Cox
Mostly this is a note for any future release managers but also a FYI
to anyone interested.

We're participating in the CVE Automation Working Group pilot to
provide CVE information via git[1].  This means when we do any future
security release of OpenSSL we can send information about each CVE
directly to Mitre (via a forked github repo and pull request) rather
than filling out their web based form.

In order to prepare for the pilot we've also switched from providing
CVE information from the Mitre plain text format to JSON[2].   The
JSON files do not have to be written by hand, 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/CVEProject/cvelist/
[2] 
https://github.com/CVEProject/automation-working-group/tree/master/cve_json_schema
[3] https://www.openssl.org/news/vulnerabilities.xml
[4] https://github.com/openssl/web/blob/master/bin/vulnxml2json.py
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project