Re: [Servercert-wg] Ballot SC-74 - Clarify CP/CPS structure according to RFC 3647

[Clint Wilson via Servercert-wg]

Hi Tim,

> On May 10, 2024, at 8:52 AM, Tim Hollebeek via Servercert-wg 
>  wrote:
> 
> Whether the comparison should be case sensitive or not is not a question of 
> how “strict” the linter should be, but what the requirements are.  Linters 
> MUST NOT make their own determinations as to what the requirements are, and 
> SHOULD highlight cases like this where ambiguity may be present.  For 
> example, it would be sensible to WARN that a value deviates in case from the 
> correct value, and that the requirements are unclear whether that’s allowed 
> (assuming SC-74 had passed in its current form).
>  
> However, I would question whether it’s actually even unclear at all.  It’s 
> impossible to interpret the highlighted language into a, b, or c, because the 
> language is completely silent on not just capitalization, but the titles 
> themselves.  I interpret the highlighted language as saying you have to 
> include at least every section and subsection, but it doesn’t matter what 
> titles you give those sections or subsections (since there’s no relevant 
> requirements).  That’s what the highlighted text says, and questions of 
> whether it has to be capitalized the same way miss the fact that it doesn’t 
> even say the same titles need to be used.
>  
> There are also some hilarious errors in 3647 if you look closely.  I think 
> the best path forward would be something along the lines of:
>  
> MUST include at least every section and subsection defined in Appendix ZZ, 
> and MUST use the section and subsection titles listed there
> The titles SHOULD be formatted, worded, capitalized and spelled the same way, 
> and
> Errors in formatting or titling sections of a CPS are not grounds for 
> revocation of affected certificates. 

Overall agreed with what’s stated here, except this part of the proposal. I do 
agree with what I believe your intent to be, but depending on how this is 
worded it seems it could lead to overly broad application (e.g. the error in 
titling “Non-verified subscriber information” results in a title of “Verified 
subscriber information”). Mostly just drawing attention to it as something that 
would need to be crafted somewhat carefully and perhaps would be preferable to 
have the MUST and SHOULD sections worded specifically enough that the intended 
allowance for errors in formatting or titling are encapsulated as clearly not 
part of the MUST requirement and clearly part of the SHOULD requirement. That 
approach would also avoid (I think) needing to consider the interaction of 
something like #3 with 4.9.1.2.(5).

Cheers,
-Clint

> And then explicitly list the outline we want in Appendix ZZ.  The outline 
> should be very close to what 3647 says, to avoid unnecessary churn or 
> deviation from IETF standards, but it would give us a chance to fix the 
> obvious errors, and perhaps fix some historical baggage.
>  
> The resulting outline could be submitted back to IETF for publication as an 
> update to 3647, which is starting to show its age.
>  
> -Tim
>  
> From: Servercert-wg  > On Behalf Of Roman Fischer via 
> Servercert-wg
> Sent: Friday, May 10, 2024 4:20 AM
> To: CA/B Forum Server Certificate WG Public Discussion List 
> mailto:servercert-wg@cabforum.org>>
> Subject: Re: [Servercert-wg] Ballot SC-74 - Clarify CP/CPS structure 
> according to RFC 3647
>  
> Hi Wendy,
>  
> I would definitely go for c) because the documents are overall not 
> standardized enough to do any kind of automatic parsing where a) or b) would 
> maybe help.
>  
> Rgds
> Roman
>  
> From: Servercert-wg  > On Behalf Of Wendy Brown - 
> QT3LB-C via Servercert-wg
> Sent: Donnerstag, 9. Mai 2024 16:58
> To: Aaron Gable mailto:aa...@letsencrypt.org>>
> Cc: CA/B Forum Server Certificate WG Public Discussion List 
> mailto:servercert-wg@cabforum.org>>
> Subject: Re: [Servercert-wg] Ballot SC-74 - Clarify CP/CPS structure 
> according to RFC 3647
>  
> OK - then I have a question for all those voting on SC74 (as an Associate 
> member rep, I do not have a vote)
> How do you interpret the proposed new language:
> include at least every section and subsection defined in section 6 of RFC 3647
>  
> Does this mean:
> a) that the section and subsection headers have to exactly match the text in 
> RFC 3647 including its use of capitalization, or 
> b) just that the words must be the same or 
> c) you just have to have the same numbering and the title can be slightly 
> different as long as it covers the intended content?
>  
> Sorry to not have asked this during the discussion period, until I saw the 
> output of the linter Aaron prepared, it didn't occur to me that anyone would 
> have interpreted it as the capitalization had to match.
>  
> thanks,
> Wendy
>  
> Wendy Brown
> Supporting GSA
> FPKIMA Technical Liaison
> Protiviti Government Services
> 703-965-2990 (cell)
>  
>  
> On Thu, May 9, 2024 at 10:33 AM Aaron Gable  

Re: Recent Entrust Compliance Incidents

['Ben Wilson' via dev-security-policy@mozilla.org]

Added " Although not expressed in the bug, it appears that certificate
revocation was delayed as well."

On Fri, May 10, 2024 at 10:54 AM George  wrote:

> Although it was not mentioned in the original bug, it may be worth adding
> that the certificates in bug 1867130
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1867130> were also not
> revoked within 5 days of discovery. Entrust might've based the start of the
> 5 day deadline at the time the "Director of compliance confirmed
> investigation conclusions to support team" at 2023-11-21 15:00 UTC with all
> certificates being revoked by 2023-11-26 14:50 UTC, but I don't think
> that's correct if that was the case.
>
> On Friday, May 10th, 2024 at 5:27 PM, 'Ben Wilson' via
> dev-security-policy@mozilla.org  wrote:
>
> Here are draft summaries of the additional historic incidents. I'll be
> adding these to the Entrust Issues page:
> https://wiki.mozilla.org/CA/Entrust_Issues
>
> *Invalid data in State/Province Field -*
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1658792
>
> It was initially discovered that Entrust had issued 395 OV SSL
> certificates to a large international organization with “NA” for the
> state/province information. Entrust worked on a drop-down list to prevent
> the error. Certificate revocation would not occur within established
> timeframes, so Bug #1658794 for delayed revocation was opened.
>
> *Late Revocation for Invalid State/Province Issue - *
> https://bugzilla.mozilla.org/show_bug.cgi?id=1658794
>
> This is the delayed revocation bug related to Bug #1658792, above. Entrust
> said that when educating large institutions about rapid revocation, factors
> include who owns a certificate, where it is deployed, and the type of
> system or application that requires the certificate. It also said that it
> was advocating automation with such institutions to help speed up
> certificate replacement and to minimize human error.
>
> *EV TLS Certificate incorrect jurisdiction -*
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1802916
>
> Entrust mis-issued 322 EV certificates with the wrong state and locality
> jurisdiction fields due to complex data entry processes. Entrust
> implemented a different automated dropdown system for jurisdiction
> selection. Certificate revocation would not occur within established
> timeframes, so Bug #1804753 for delayed revocation was opened.
>
> *Delayed Revocation for EV TLS Certificate incorrect jurisdiction - *
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1804753
>
> This is the delayed revocation bug related to Bug #1802916, above. Entrust
> listed 8 Subscribers who were pushing back on immediate certificate
> revocation and the reasons given (e.g. extensions granted due to
> end-of-year freezes). Entrust committed to “continue to develop and extend
> methods for automatic certificate renewal.”
>
> *Jurisdiction Locality Wrong in EV Certificate -*
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1867130
>
> Two EV TLS Certificates were mis-issued due to human error in the
> Jurisdiction Locality field. (The incident revealed 340 additional accounts
> needing similar updates.) Entrust said it would enhance its linting
> processes to include possibly using an external service to validate
> locality data against verified country data.
>
> *SHA-256 hash algorithm used with ECC P-384 key - *
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1648472
>
> A Mozilla policy was adopted to require hashing with SHA-384 for an ECC
> P-384 key. Existing CAs using SHA-256 were not re-configured when Mozilla
> adopted this policy. This incident revealed a serious gap in taking new
> requirements and implementing them. Ryan Sleevi noted that linting was just
> a safety net and not a systemic solution. Entrust was also criticized for
> the lack of detail in its incident report and its decision to not revoke
> the certificates.
>
> Entrust committed to improving its monitoring and implementation of policy
> changes to prevent similar incidents. Ryan set forth a number of proactive
> systemic corrections that Entrust needed to take, rather than taking a
> reactive stance on matters of non-compliance.
>
> Entrust committed to rigorous review of certificate profiles, browser
> policy revisions, and industry developments. As a final comment, Ryan said,
> “My big concern is, going forward, we see incident reports from Entrust
> take a more systemic, holistic response, like Comment #16, to try and cover
> the scenarios, and to provide sufficient detail about the situation and its
> failures to understand how those relate. The goal isn't to make CAs wear
> proverbial sackcloth, it's to try and make sure we're understanding how
>

Re: Recent Entrust Compliance Incidents

['Ben Wilson' via dev-security-policy@mozilla.org]

 PM Watson Ladd  wrote:

> Could we add a section for geographical incidents? This is slightly
> outside your time window, but I think reading the series here has some
> uncanny echos in the ones in your window.
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1658792
> https://bugzilla.mozilla.org/show_bug.cgi?id=1658794
> https://bugzilla.mozilla.org/show_bug.cgi?id=1802916
> https://bugzilla.mozilla.org/show_bug.cgi?id=1804753
> https://bugzilla.mozilla.org/show_bug.cgi?id=1867130
>
> On Tue, May 7, 2024 at 7:59 AM 'Ben Wilson' via
> dev-security-policy@mozilla.org 
> wrote:
> >
> > Dear Mozilla Community,
> >
> > Over the past couple of months, a substantial number of compliance
> incidents have arisen in relation to Entrust. We have summarized these
> recent incidents in a dedicated wiki page:
> https://wiki.mozilla.org/CA/Entrust_Issues. In brief, these incidents
> arose out of certificate mis-issuance due to a misunderstanding of the EV
> Guidelines, followed by numerous mistakes in incident handling (including a
> deliberate decision to continue mis-issuance), which have been compounded
> by a failure to remediate the issues in a timely fashion in line with
> well-established norms and root store requirements.
> >
> > Our preliminary assessment of these incidents is that while they were
> relatively minor initially, the poor incident response has substantially
> aggravated them and the progress towards full remediation remains
> unacceptably slow. This is particularly disappointing in light of previous
> incidents in 2020 (#1651481 and #1648472), which arose out of similar
> misunderstandings of the requirements, similar poor decision-making in the
> initial response, and lengthy remediation periods that fell well below
> expectations. Entrust gave commitments in those bugs to address the root
> problems through process improvements, and it is concerning to see so
> little improvement 4 years later.
> >
> > In light of these recent incidents, we are requesting that Entrust
> produce a detailed report of them. This report should cover in detail:
> >
> > The factors and root causes that lead to the initial incidents,
> highlighting commonalities among the incidents and any systemic failures;
> >
> > Entrust’s initial incident handling and decision-making in response to
> these incidents, including any internal policies or protocols used by
> Entrust to guide their response and an evaluation of whether their
> decisions and overall response complied with Entrust’s policies, their
> practice statement, and the requirements of the Mozilla Root Program;
> >
> > A detailed timeline of the remediation process and an apportionment of
> delays to root causes; and
> >
> > An evaluation of how these recent issues compare to the historical
> issues referenced above and Entrust’s compliance with its previously stated
> commitments.
> >
> > Finally, Entrust’s report should include a detailed proposal on how it
> plans to address the root causes of these issues. In light of previous
> guarantees given by Entrust in 2020 to ensure speedy remediation in future
> incidents, this proposal should include:
> >
> > Clear and concrete steps that Entrust proposes to take to address the
> root causes of these incidents and delayed remediation;
> >
> > Measurable and objective criteria for Mozilla and the community to
> evaluate Entrust’s progress in deploying these solutions; and
> >
> > A timeline for which Entrust will commit to meeting these criteria.
> >
> > We strongly recommend that Entrust go beyond their existing commitment
> to offer systematic, automated solutions for effective remediation, like
> ACME ARI and that it also include clear and measurable targets for the
> adoption of these tools by new and existing subscribers.
> >
> > This report should be submitted to Mozilla dev-security-policy mailing
> list for evaluation by the community and Mozilla, who will weigh whether
> Entrust’s report presents a credible and effective path towards
> re-establishing trust in Entrust’s operation. Submission should be no later
> than June 7, 2024.
> >
> > We thank community members for their engagement on these issues and look
> forward to their feedback on Entrust’s report and proposed commitments.
> >
> >  Thanks,
> >
> > Ben Wilson
> >
> > Mozilla Root Program
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "dev-security-policy@mozilla.org" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to dev-security-policy+unsubscr...@moz

[Sprinklerforum] Standpipe NFPA14 2019

[Chris Wilson]

To all,
I have a 4 story building with 2 exit stairways I am installing a class I 
manual wet standpipe combination sprinkler system. The remote stair is on the 
interior of the building and has a rated exit passageway  on the first floor 
that is 73' long. I am placing all hose valves on the main floor landings and 
one a the exit door of the exit passage way.

I am planning on calculating 500 gpm from the remote stand pipe and 250 for the 
2nd standpipe. The exit passage way hose connection will be fed by a  2/12 
lateral pipe fed from the  4" horizontal supply to the remote standpipe as it 
pass by the exit passageway.

Do I need to include an additional 250 gpm in my calcs at the hose valve at the 
exit passageway?

Thanks
Christopher S. Wilson SET
Project Design Manager
Treasure Valley Fire Protection
2731 S. Saturn Way
Boise, ID 83709
Phone:  208-362-1888
Fax: 208-362-2207

please note all TVFP email
addresses have changed
new email below

chr...@tvfpinc.com<mailto:chr...@tvfp.us>


_
SprinklerForum mailing list:
https://lists.firesprinkler.org/list/sprinklerforum.lists.firesprinkler.org
To unsubscribe send an email to sprinklerforum-le...@lists.firesprinkler.org

[Translators-l] Tech News #20, 2024

[Nick Wilson (Quiddity)]

The latest tech newsletter is ready for early translation:
https://meta.wikimedia.org/wiki/Tech/News/2024/20

Direct translation link:
https://meta.wikimedia.org/w/index.php?title=Special:Translate=page-Tech%2FNews%2F2024%2F20=page

We plan to send the newsletter on Monday afternoon (UTC). The existing
translations will be posted on the wikis in that language. Deadlines:
https://meta.wikimedia.org/wiki/Tech/News/For_contributors#The_deadlines

There will be more edits by Friday afternoon UTC but the existing content
should generally remain fairly stable. I will let you know on Friday in any
case.

Let us know if you have any questions, comments or concerns. As always, we
appreciate your help and feedback.

(If you haven't translated Tech News previously, see this email:
https://lists.wikimedia.org/pipermail/translators-l/2017-January/003773.html
)

Thank you!

-- 
Nick "Quiddity" Wilson (he/him)
Movement Communications Specialist
Wikimedia Foundation
___
Translators-l mailing list -- translators-l@lists.wikimedia.org
To unsubscribe send an email to translators-l-le...@lists.wikimedia.org

Re: [Smcwg-public] Background for discussion of Legacy Profiles

[Clint Wilson via Smcwg-public]

Hi,

I agree with your summary, Ben, but am struggling with the “how” and the “when”.

I don’t know if I’m alone in this, but it would be helpful to me to have the 
concerns that have been raised also outlined in text somewhere (ideally with 
details and data and all that good stuff). To be honest, at this point I’m not 
entirely sure which concerns were addressed as part of the discussion on recent 
calls, which concerns are outstanding, what the proposed remediation(s) or 
resolution(s) might be from both those who share the concerns and those who 
don’t, what questions related to individual concerns remain unanswered, what 
data exists to give any indication regarding the likely overall impact for each 
concern, or really what the path forward looks like.

Apple had originally planned to restrict S/MIME validity periods to 2 years 
(something Gmail has done for a long time, aiui). Instead, that limit was 
increased to 3 years in 2021 based on an understanding from CAs that 
substantive efforts would be made to ensure the future deprecation of this 
longer validity period and a _very_ clear indication that deprecation of the 
Legacy profile was part of this. In the interim 2.5 years, many CAs *have* 
honored those commitments and successfully established systems, processes, 
communication channels, and automation capabilities reinforcing that 
future-facing outlook. On the other hand, in the interim 2.5 years, I have 
*not* seen topics raised by CAs related to the purported negative impact of 
deprecating the Legacy profile except recently and in direct response to 
Stephen's oft-repeated and impressively diligent inquiries regarding the topic. 
Even then, I have not seen problems defined in sufficient detail to allow for 
ecosystem-level solutions to be proposed, designed, or iterated upon.

As in 2021, so today: I am committed to trying to solve these issues, but more: 
to understand and to incorporate that understanding in driving a balanced 
approach to iterative improvement to the SBRs. However, the seemingly 
unchanging status quo related to attempts to discuss and establish timelines 
for reducing S/MIME certificate validity periods is not encouraging confidence 
in this approach.

Disruption is never the goal, but it *is* often an inevitability. In the same 
vein, avoiding disruption is also not the goal; an expectation that disruption 
be completely avoided is no different than a moratorium on future changes to 
the SBRs. Rather, at least in my mind, it’s the level of disruption that we 
should be focused on reducing.

Also, just to repeat again one point: establishing a deprecation date for the 
Legacy profile is likely the _only_ way we actually can ensure that those not 
involved in the S/MIME WG are prepared (or even aware of the need *to* prepare) 
for a shift away from the Legacy profile. If there’s not a target, no one’s 
gonna be aiming anything.

Thanks,
-Clint


> On May 9, 2024, at 2:27 PM, Ben Wilson via Smcwg-public 
>  wrote:
> 
> Hi all,
> 
> I am currently aligned with Wendy’s and Judith’s concerns expressed on the 
> recent call about sunsetting the Legacy profile, but I look forward to 
> discussing this further in Bergamo. The Legacy profile provides greater 
> flexibility, and migrating to only the Multipurpose and Strict profiles may 
> have unforeseen consequences. While no one else has explicitly stated they 
> are not ready for this move, the Mozilla Root Program has integrated the 
> S/MIME BRs into our root store policy, necessitating support for diverse use 
> cases while ensuring broad compliance. We need to ensure that everyone not 
> involved in the S/MIME WG is prepared for such a significant move, and we 
> might find out about problems when it is too late to address them. For 
> instance, we could see compliance issues in Bugzilla from CA operators who 
> are currently enabled with the email trust bit, or we might receive a root 
> inclusion request from a CA operator unwilling or unable to restrict issuance 
> to only strict or multipurpose certificates.
> 
> In summary, I'd just like to understand the issues better and minimize 
> disruption and compliance issues down the road. 
> 
> I look forward to your thoughts and suggestions.
> 
> Thanks,
> 
> Ben
> 
> 
> 
> On Thu, Apr 11, 2024 at 8:40 AM Stephen Davidson via Smcwg-public 
> mailto:smcwg-public@cabforum.org>> wrote:
>> Hello all:
>> 
>>  
>> 
>> I attach the summary that we reviewed in the SMCWG call yesterday.
>> 
>>  
>> 
>> It highlights the differences between the Legacy generation profiles and the 
>> Multipurpose/Strict profiles, including links to the relevant text sections 
>> in the S/MIME BR.
>> 
>>  
>> 
>> https://cabforum.org/posts/2024/2024-04-10-legacy-deprecation/SMCWG_20240410_Final.pdf
>

[grpc-io] Call for Speakers! 10 Days left to submit a gRPConf 2024 proposal

['Terry Wilson' via grpc.io]

Hello gRPC Community,


We still have slots available for speakers to join us at gRPConf 2024. If  
you have a gRPC story to tell, an innovative use case to share, or a 
burning question to answer, we invite you to submit a proposal by May 19th!

Submit a Proposal 

Why you should speak:

   - 
   
   Share your gRPC knowledge
   - 
   
   Become a recognized expert
   - 
   
   Connect with fellow gRPC users
   
We want to hear about:

   - 
   
   How you're using gRPC
   - 
   
   Tips and tricks you've learned
   - 
   
   New ideas for gRPC projects
   
Keep an eye on the official gRPC website and social media channels for 
updates. If you’re not interested in speaking, but still want to join us 
you can Register Now! 

We can't wait to see you at gRPConf 2024!

The gRPConf Team

events.linuxfoundation.org/grpconf/ 
Follow us on Youtube @gRPCio 


-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/4388e8e4-98f6-47c9-86b9-101ad580de06n%40googlegroups.com.

Re: [Smcwg-public] Background for discussion of Legacy Profiles

[Ben Wilson via Smcwg-public]

Hi all,

I am currently aligned with Wendy’s and Judith’s concerns expressed on the
recent call about sunsetting the Legacy profile, but I look forward to
discussing this further in Bergamo. The Legacy profile provides greater
flexibility, and migrating to only the Multipurpose and Strict profiles may
have unforeseen consequences. While no one else has explicitly stated they
are not ready for this move, the Mozilla Root Program has integrated the
S/MIME BRs into our root store policy, necessitating support for diverse
use cases while ensuring broad compliance. We need to ensure that everyone
not involved in the S/MIME WG is prepared for such a significant move, and
we might find out about problems when it is too late to address them. For
instance, we could see compliance issues in Bugzilla from CA operators who
are currently enabled with the email trust bit, or we might receive a root
inclusion request from a CA operator unwilling or unable to restrict
issuance to only strict or multipurpose certificates.

In summary, I'd just like to understand the issues better and minimize
disruption and compliance issues down the road.

I look forward to your thoughts and suggestions.

Thanks,

Ben


On Thu, Apr 11, 2024 at 8:40 AM Stephen Davidson via Smcwg-public <
smcwg-public@cabforum.org> wrote:

> Hello all:
>
>
>
> I attach the summary that we reviewed in the SMCWG call yesterday.
>
>
>
> It highlights the differences between the Legacy generation profiles and
> the Multipurpose/Strict profiles, including links to the relevant text
> sections in the S/MIME BR.
>
>
>
>
> https://cabforum.org/posts/2024/2024-04-10-legacy-deprecation/SMCWG_20240410_Final.pdf
>
>
>
> This should facilitate review and feedback to help the SMCWG determine
> appropriate steps and timelines to migrate to the Multipurpose/Strict
> profiles.
>
>
>
> Regards, Stephen
> ___
> Smcwg-public mailing list
> Smcwg-public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/smcwg-public
>
___
Smcwg-public mailing list
Smcwg-public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/smcwg-public

[RBW] Re: Susie green color discrepancy

[Aaron Wilson]

Thanks Tio Ryan. 

Of note, my green Susie just shipped. Exciting. 

On Thursday, May 9, 2024 at 12:24:54 PM UTC-6 tio ryan wrote:

> I have a sergio green platypus and the color is much more like the riv 
> pics than the blue lug image — the tan sidewalls on the wtb tires looks off 
> as well. 
>
> rest assured, sergio green is a lovely color in person (imo) 
>
> -tio in bk 
>
> On Thursday, May 9, 2024 at 1:58:17 PM UTC-4 tal...@gmail.com wrote:
>
>> Maybe it is just a white balance issue. They just look so starkly 
>> different. 
>>
>> On Thursday, May 9, 2024 at 11:50:26 AM UTC-6 Joe Bernard wrote:
>>
>>> I don't think that 'against a drab white wall' shot is going to be 
>>> indicative of how Sergio Green will look outside while riding. 
>>>
>>> On Thursday, May 9, 2024 at 10:31:58 AM UTC-7 tal...@gmail.com wrote:
>>>
 Saw Blue Lug's most recent Instagram story with what looks like some 
 pictures of the new Susies in both colors. The green looks substantially 
 different than the image on Riv's website. Makes me wish I'd ordered an 
 orange...




-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/bb7a9f86-81a6-4f60-b31f-a32b2f03f19en%40googlegroups.com.

[RBW] Re: Susie green color discrepancy

[Aaron Wilson]

Maybe it is just a white balance issue. They just look so starkly 
different. 

On Thursday, May 9, 2024 at 11:50:26 AM UTC-6 Joe Bernard wrote:

> I don't think that 'against a drab white wall' shot is going to be 
> indicative of how Sergio Green will look outside while riding. 
>
> On Thursday, May 9, 2024 at 10:31:58 AM UTC-7 tal...@gmail.com wrote:
>
>> Saw Blue Lug's most recent Instagram story with what looks like some 
>> pictures of the new Susies in both colors. The green looks substantially 
>> different than the image on Riv's website. Makes me wish I'd ordered an 
>> orange...
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/11ced9d1-5942-4eae-ba42-4e4d4a378dbcn%40googlegroups.com.

Re: [Servercert-wg] [Voting Begins] Ballot SC-74 - Clarify CP/CPS structure according to RFC 3647

[Ben Wilson via Servercert-wg]

Mozilla changes its vote to "no" on Ballot SC-74 with the understanding
that additional edits are needed.

On Sun, May 5, 2024 at 1:05 PM Ben Wilson  wrote:

> Mozilla votes "yes" on Ballot SC-74.
>
> On Sun, May 5, 2024 at 3:06 AM Dimitris Zacharopoulos (HARICA) via
> Servercert-wg  wrote:
>
>> HARICA votes "yes" to ballot SC-74.
>>
>> On 5/5/2024 11:24 π.μ., Dimitris Zacharopoulos (HARICA) via Servercert-wg
>> wrote:
>>
>> Voting begins for ballot SC-74.
>> SC-74 - Clarify CP/CPS structure according to RFC 3647 Summary
>>
>> The TLS Baseline Requirements require in section 2.2 that:
>>
>> *"The Certificate Policy and/or Certification Practice Statement MUST be
>> structured in accordance with RFC 3647 and MUST include all material
>> required by RFC 3647."*
>>
>> The intent of this language was to ensure that all CAs' CP and/or CPS
>> documents contain a similar structure, making it easier to review and
>> compare against the BRs. However, there was some ambiguity as to the actual
>> structure that CAs should follow. After several discussions in the SCWG
>> Public Mailing List
>> <https://lists.cabforum.org/pipermail/servercert-wg/2023-November/004070.html>
>> and F2F meetings, it was agreed that more clarity should be added to the
>> existing requirement, pointing to the outline described in section 6 of RFC
>> 3647.
>>
>> The following motion has been proposed by Dimitris Zacharopoulos (HARICA)
>> and endorsed by Aaron Poulsen (Amazon) and Tim Hollebeek (Digicert).
>>
>> You can view the github pull request representing this ballot here
>> <https://github.com/cabforum/servercert/pull/503>.
>> Motion Begins
>>
>> MODIFY the "Baseline Requirements for the Issuance and Management of
>> Publicly-Trusted TLS Server Certificates" based on Version 2.0.4 as
>> specified in the following redline:
>>
>>-
>>
>> https://github.com/cabforum/servercert/compare/c4a34fe2292022e0a04ba66b5a85df75907ac2a2...f6a90e2a652fbb7a2d62a976b70f4af3adce8dae
>>
>> Motion Ends
>>
>> This ballot proposes a Final Maintenance Guideline. The procedure for
>> approval of this ballot is as follows:
>> Discussion (at least 7 days)
>>
>>- Start time: 2024-04-25 16:30:00 UTC
>>- End time: on or after 2024-05-02 16:30:00 UTC
>>
>> Vote for approval (7 days)
>>
>>- Start time: 2024-05-05 8:30:00 UTC
>>- End time: 2024-05-12 8:30:00 UTC
>>
>>
>>
>> ___
>> Servercert-wg mailing 
>> listServercert-wg@cabforum.orghttps://lists.cabforum.org/mailman/listinfo/servercert-wg
>>
>>
>> ___
>> Servercert-wg mailing list
>> Servercert-wg@cabforum.org
>> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>>
>
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

Re: [blink-dev] Intent to Ship: Tabbed web apps

[Brett Wilson]

On Wed, May 8, 2024 at 8:39 AM Alex Russell 
wrote:

> I'm happy for this to be CrOS first, but would like to unpack Brett's
> statement above a bit. If we (MSFT) were to polish this up for Windows,
> would patches for that be accepted?
>

I can't speak for the browser team. But my current understanding is that
the browser team likes this in principle but doesn't prioritize it high
enough to work on it right now (this is a correction from my previous
assertion). So I'm pretty sure patches enabling this for other platforms
would be accepted.

Brett

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABiGVV-Zeyv3Rez%2BPQ%2B%2BfW4ihpRCwnnGN2HNxOyXTA7_uWehzw%40mail.gmail.com.

Re: [go-cd] GOCD restart issue

[Chad Wilson]

Did someone recently change something in your compose volume mounts?

It's probably not a good idea to mount things directly into /go-working-dir
like the line "*-
./gocd/docker-elastic-agents-3.2.3-415.jar:/go-working-dir/plugins/external*
"

The container entrypoint expects to own and manage these locations with
symlinks, as Ram mentioned earlier. This is why the */go-working-dir* path
is not documented - it is internal and you shouldn't interfere with it or
couple your config to undocumented internals.

This mount being there at container start is probably going to prevent the
entrypoint from linking things to /godata correctly and you will probably
end up with a `plugins` directory which is not writable by GoCD and errors
like you had below.

Since you already have a /godata volume - put the plugin jars directly into
./gocd/data/plugins/external (on your host machine), and remove the
individual jar mount. Basically, please follow the documentation:
https://hub.docker.com/r/gocd/gocd-server

If removing that plugin mount still doesn't work, check the other mounts
and the permissions of those directories as seen by the container when it
starts by execing into it and exploring.

-Chad

On Tue, May 7, 2024 at 11:48 PM Vijayakumaran A. <
vijayakumara...@praniontech.com> wrote:

> We have started container using docker start servicename.
>
> Here is the composer file of gocd server part
>
> server:
> container_name: gocd-server
> image: gocd/gocd-server:v23.4.0
> restart: always
> ports:
>   - "8153:8153"
> volumes:
>   - ./gocd/data:/godata
>   - ./gocd/data/home:/home/go
>   - ./gocd/scripts/server:/docker-entrypoint.d
>   - ./gocd/scripts/shared:/shared
>   - ./gocd/passwd:/godata/config/passwd
>   -
> ./gocd/docker-elastic-agents-3.2.3-415.jar:/go-working-dir/plugins/external
> networks:
>   - gocd
>
>
>
> On Tuesday, May 7, 2024 at 9:05:30 PM UTC+5:30 Chad Wilson wrote:
>
>> Please share how you are starting the container and what mounts you are
>> using, especially to /godata.
>>
>> Your container may have permissions issues writing to /godata or issues
>> mounting the filesystem in writeable mode. Is it some kind of NFS volume?
>> Is it mounted by another container/host already and thus is being mounted
>> in read-only mode? is this a Helm/Kubernetes install, or just a regular
>> container on a server?
>>
>> You can exec into the container and check /godata and /go-working-dir are
>> writable by the `go` user.
>>
>> -Chad
>>
>> On Tue, May 7, 2024 at 11:21 PM Sriram Narayanan 
>> wrote:
>>
>>>
>>>
>>> On Tue, May 7, 2024 at 10:33 PM Vijayakumaran A. <
>>> vijayak...@praniontech.com> wrote:
>>>
>>>> Team,we have just restarted the gocd container now gocd not started.
>>>>
>>>> Having below in docker logs please help
>>>> [image: go1.PNG][image: go2.PNG]
>>>>
>>>>
>>> Looks like something is wrong with the container system.
>>> /go-working-dir/ is a runtime symlink directory created here
>>> https://github.com/gocd/docker-gocd-server/blob/master/docker-entrypoint.sh#L41
>>>
>>> If a directory is not getting created, then there is an underlying issue
>>> unrelated to GoCD and entirely related to the underlying container system.
>>> Please see if a container restart helps you continue. You should also check
>>> the container system's logs. To share something that we saw at our project
>>> two weeks ago, one of the EKS clusters was still running at version 1.23
>>> and we would often see the error "Out of storage space" (sometimes once a
>>> day). When I'd exec into the container, I found that we were unable to make
>>> directories but were able to create files. We upgrades to EKS 1.24 and that
>>> error has not recurred since then.
>>>
>>> I also see that you are using GoCD 23.4 and the H2DB. If this is a GoCD
>>> setup that you are using for your project, then I urge you to use the
>>> postgres database instead. See
>>> https://github.com/gocd/gocd-database-migrator
>>>
>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "go-cd" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to go-cd+un...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/go-cd/5df023fd-f859-4a6b-99e7-92e3063653e7n%40googlegroups.co

Re: [go-cd] Mount .ssh from EFS to the container (from the image gocd/gocd-server:v22.3.0)

[Chad Wilson]

To add onto the many options here, if you only need the SSH keys to be used
by Git for clones etc, you can entirely customise how GIT uses SSH using
the *GIT_SSH_COMMAND* env var
;
set at the container level.

GIT_SSH_COMMAND="ssh -i /path/to/your/private/key"

Then you can put the private key anywhere you like (including /godata - not
just the home dir) which the GoCD server/agent has access to (as long as it
has the right file permissions (400 or 600) and is readable by
`go`/UID=1000 user, as Ram notes).

-Chad

On Tue, May 7, 2024 at 11:11 PM Sriram Narayanan 
wrote:

>
>
> On Mon, May 6, 2024 at 3:30 AM Jason Smyth  wrote:
>
>> Hi Satya,
>>
>> A possible workaround to the limitation is updating the server image and
>> adding a symlink that points ~/.ssh/ to wherever you want to actually mount
>> the data.
>>
>> I have never experimented with using a symlink for the .ssh directory,
>> though, so this may not work.
>>
>
> I haven't tried this yet, but one would explore adding a custom shell
> script at the /docker-entrypoint.d/ mount point which could create such a
> symlink
>
> Nice tip, Jason.
>
>
>>
>> Hope this helps,
>> Jason
>>
>>
>> On Sunday 28 April 2024 at 12:12:16 UTC-4 Sriram Narayanan wrote:
>>
>>> On Sat, Apr 27, 2024 at 7:10 PM Satya Elipe  wrote:
>>>
 Thank you Sriram.

 So, ".ssh" folder mounting will be separate from the rest of the data
 (/godata, for plugins, pipelines, db etc)...so there would be two separate
 mount points into the container ?

 I'm using ECS at the moment and not kubernetes, so my task definition
 will have two mount points like below:

 ```

 "mountPoints": [
 {
 "sourceVolume": "efs_id:/godata",

 "containerPath": "/godata"
 },
 {
 "sourceVolume": "efs_id:/godata/.ssh",

 "containerPath": "/home/go/.ssh"
 }
 ],

 ```

 So mounting /godata and efs_id:/godata/.ssh from EFS into the
 container at /godata and /home/go/.ssh locations respectively (per
 above code) seems to work.

 In this case entry_point.sh from the base image is able to
 map/consider and execute them properly, hence the server is up and running
 and functioning properly.

 Is that the way it has to be, I think the github repo for gocd server
 says that I guess, but perhaps I feel that extra mount point just for .ssh
 is overkill and if .ssh can also be entertained by entry_point.sh from one
 single mount point /godata in my case, that would be great ?

 If I do not mount .ssh into /home/go/.ssh separately into the container
 - things seem to fail complaining that "key verification failed", I'm not
 sure whether I'm still missing something here.

>>>
>>> Hey, I had got caught by surprise earlier during the "elastic agent"
>>> discussions and had assumed that you must be using EKS. Sorry, my bias had
>>> clouded my judgement then. Thankfully Chad and you cleared that up.
>>>
>>> ssh by default checks ~/.ssh/ for the keys. Within the GoCD server and
>>> agent containers, this home (~) is the /home/go directory, and hence we
>>> mount the .ssh folder there. There are use cases where the keys are made
>>> available via a different network share and not mixed with configurations
>>> that regular GoCD admins would have access to, and hence being able to
>>> mount from a separate place to ~/.ssh is helpful. You could always place
>>> the .ssh directory along side other directories that would get to godata,
>>> while also explicitly specifying a mount to /home/go. At present, GoCD does
>>> not have a configuration option to point it to a private key at a path
>>> other than ~/ssh
>>>
>>> https://docs.gocd.org/current/faq/docker_container_ssh_keys.html
>>>
>>>

 Many thanks
 Satya

 On Thu, Apr 25, 2024 at 3:31 PM Sriram Narayanan 
 wrote:

>
>
> On Thu, Apr 25, 2024 at 10:16 PM Satya Elipe 
> wrote:
>
>> Hi all
>>
>> Wonder, what's the way around to mount .ssh from EFS into the gocd
>> base container (from the image gocd/gocd-server:v22.3.0).
>>
>>
>> We have saved all our content into EFS under /godata and maps that
>> into the container as /godata.
>>
>>
>> We are using gocd/gocd-server:v22.3.0.
>>
>>
>> It all runs good, mapping was fine too but just one thing that’s not
>> happening is “.ssh” folder.
>>
>>
>> I have .ssh with all required keys in EFS under /godata and /godata
>> within the container also has .ssh but not /go-working-dir.
>>
>>
>> Is that supported, am I mis-configuring it, or do we need to handle
>> that outside of the base image ?
>>
>

Recent Entrust Compliance Incidents

['Ben Wilson' via dev-security-policy@mozilla.org]

Dear Mozilla Community,

Over the past couple of months, a substantial number of compliance
incidents have arisen in relation to Entrust. We have summarized these
recent incidents in a dedicated wiki page:
https://wiki.mozilla.org/CA/Entrust_Issues. In brief, these incidents arose
out of certificate mis-issuance due to a misunderstanding of the EV
Guidelines, followed by numerous mistakes in incident handling (including a
deliberate decision to continue mis-issuance), which have been compounded
by a failure to remediate the issues in a timely fashion in line with
well-established norms and root store requirements.

Our preliminary assessment of these incidents is that while they were
relatively minor initially, the poor incident response has substantially
aggravated them and the progress towards full remediation remains
unacceptably slow. This is particularly disappointing in light of previous
incidents in 2020 (#1651481
<https://bugzilla.mozilla.org/show_bug.cgi?id=1651481> and #1648472
<https://bugzilla.mozilla.org/show_bug.cgi?id=1648472>), which arose out of
similar misunderstandings of the requirements, similar poor decision-making
in the initial response, and lengthy remediation periods that fell well
below expectations. Entrust gave commitments
<https://bugzilla.mozilla.org/show_bug.cgi?id=1651481#c17> in those bugs to
address the root problems through process improvements, and it is
concerning to see so little improvement 4 years later.

In light of these recent incidents, we are requesting that Entrust produce
a detailed report of them. This report should cover in detail:

   -

   The factors and root causes that lead to the initial incidents,
   highlighting commonalities among the incidents and any systemic failures;
   -

   Entrust’s initial incident handling and decision-making in response to
   these incidents, including any internal policies or protocols used by
   Entrust to guide their response and an evaluation of whether their
   decisions and overall response complied with Entrust’s policies, their
   practice statement, and the requirements of the Mozilla Root Program;
   -

   A detailed timeline of the remediation process and an apportionment of
   delays to root causes; and
   -

   An evaluation of how these recent issues compare to the historical
   issues referenced above and Entrust’s compliance with its previously stated
   commitments.

Finally, Entrust’s report should include a detailed proposal on how it
plans to address the root causes of these issues. In light of previous
guarantees <https://bugzilla.mozilla.org/show_bug.cgi?id=1651481#c17> given
by Entrust in 2020 to ensure speedy remediation in future incidents, this
proposal should include:

   -

   Clear and concrete steps that Entrust proposes to take to address the
   root causes of these incidents and delayed remediation;
   -

   Measurable and objective criteria for Mozilla and the community to
   evaluate Entrust’s progress in deploying these solutions; and
   -

   A timeline for which Entrust will commit to meeting these criteria.

We strongly recommend that Entrust go beyond their existing commitment
<https://bugzilla.mozilla.org/show_bug.cgi?id=1886532#c0> to offer
systematic, automated solutions for effective remediation, like ACME ARI
and that it also include clear and measurable targets for the adoption of
these tools by new and existing subscribers.

This report should be submitted to Mozilla dev-security-policy mailing list
for evaluation by the community and Mozilla, who will weigh whether
Entrust’s report presents a credible and effective path towards
re-establishing trust in Entrust’s operation. Submission should be no later
than June 7, 2024.

We thank community members for their engagement on these issues and look
forward to their feedback on Entrust’s report and proposed commitments.

 Thanks,

Ben Wilson

Mozilla Root Program

-- 
You received this message because you are subscribed to the Google Groups 
"dev-security-policy@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dev-security-policy+unsubscr...@mozilla.org.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaYURqFzRqVmJdc7fBXE1mbGs25HpSkp5wZ0Xm%2BRG0YHCA%40mail.gmail.com.

Re: comment on Entrust_Issues wiki page

['Ben Wilson' via dev-security-policy@mozilla.org]

All,
I hadn't announced this page yet, hoping to reference it in an email
currently undergoing internal review. But thanks for your comment.
I'll see about posting the email as soon as I can.
Thanks,
Ben

On Mon, May 6, 2024 at 3:58 PM Mike Shaver  wrote:

> The page lists the following issue:
>
> “
> 5. EV Certificate missing Issuer’s EV Policy OID -
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1888714
>
> Entrust issued 1,963 EV TLS certificates September 11-22, 2023, without
> including an EV TLS CP OID. Root Causes were the misinterpretation of the
> EV Guidelines and the TLS BRs and a failure to recognize the overriding
> requirements of the EV Guidelines. (A misinterpretation of standards led to
> non-compliant certificates, and linting failed to detect the issue.) As
> remediation, since April 11, 2024, Entrust has used pkilint as a
> post-issuance linter to detect similar issues. (Mis-issued certificates are
> a subset of the certificates disclosed and being revoked under bug
> #1883843 . Status
> of revocation is listed in bug #1886532
> .)
>
> *Issues:* Misinterpretation of Requirements; Policy/Procedure Failure;
> Certificate Mis-issuance”
>
> In my opinion it should also list that Entrust promised to provide a full
> list of affected certs and an incident report by April 5th, and continued
> to comment in the bug, but did not post that list or the IR until April
> 10th. No comment was made about a delay, or the reason that it was
> necessary.
>
> Mike
>
>
> --
> You received this message because you are subscribed to the Google Groups "
> dev-security-policy@mozilla.org" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dev-security-policy+unsubscr...@mozilla.org.
> To view this discussion on the web visit
> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CADQzZqsbubH8_7-NNxC7E7FbV%2BCqBPF%3DaYR2GseNCjy1mqEXHA%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"dev-security-policy@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dev-security-policy+unsubscr...@mozilla.org.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtabKSQhyHSPeh6iEki4mkH9Kkky0Wpes8YyB2-xsEnNu1w%40mail.gmail.com.

[cabfpub] Discussion Period Begins: Ballot FORUM-022: Establish Forum IPR Subcommittee

[Ben Wilson via Public]

*Ballot FORUM-022:  Establish Forum IPR Subcommittee*



Proposed by Ben Wilson of Mozilla and endorsed by Roman Fischer of
SwissSign and Clint Wilson of Apple.



*Purpose of Ballot*



The CA/Browser Forum’s Intellectual Property Rights (IPR) Policy and
associated documentation were last revised in 2018. Since then, there have
been requests for clarification about application of the IPR Policy to
contributions of non-Forum Members, and sections of the IPR Policy and
documentation have been identified as needing amendment, including the form
for filing and handling of Essential Claim Exclusion Notices. It is
proposed that a Charter be adopted establishing a Forum IPR Subcommittee
(FIPR) and that the proposed scope of the FIPR be to update and improve the
IPR Policy and associated documentation and to discuss the following:



(a) How to address contributions provided by non-Forum Members (e.g.,
invited experts, guest speakers, researchers, etc.);

(b) If any clarifications and/or changes are necessary to the IPR Policy in
view of recent events; and

(c) A potential contributor license agreement for the Forum’s GitHub
repository and policy for contributing to the Forum’s GitHub repository.



*Following the passage of this ballot:*

   - A new Forum IPR Subcommittee will be formed under the CA/Browser
   Forum, as outlined in section 5.6 of the Bylaws (Forum Subcommittees);
   - Mailing list(s), GitHub repository(ies), Wiki resource(s), and other
   collaboration tools will be established as needed to enable the Forum
   Subcommittee to fulfill its charter; and
   - The Forum Subcommittee will publish a set of recommended revisions to
   the IPR Policy and associated documentation for the Forum to adopt.



*MOTION BEGINS*



*Establish Forum IPR Subcommittee*



Upon approval from the CA/Browser Forum by ballot in accordance with
sections 2.3 and 5.6 of the Forum Bylaws, the Forum IPR Subcommittee
(“FIPR”) is created to perform the activities as specified in the Charter,
which is found here:



https://github.com/cabforum/forum/compare/30de00ae9672088cf618706b9e7c464fa8c34c51...b50bc495ced317c437ed6b397bb4fb574484b56b



*MOTION ENDS*



*The procedure for approval of this ballot is as follows:*



*Discussion* (7+ days)



*Start Time*: 2024-May-06 22:00 UTC

*End Time*: After 2024-May-13 22:00 UTC



*Vote for approval* (7 days)



Start Time: TBD

End Time: TBD
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

Re: GESO: A bonanza of dakotas

[mike wilson]

And a nice Convair.  We don't see those over here.  In fact, any delta wing 
except for various Mirages and the (very) odd SAAB is quite unusual.  
> On 05/05/2024 22:47 BST Larry Colen  wrote:
> 
>  
> I first saw this airport on a hike about a year ago, I finally rode my bike 
> down to Flabob yesterday afternoon.
> 
> https://www.flickr.com/photos/ellarsee/albums/72177720316721251/
> 
> --
> Larry Colen
> l...@red4est.com.   sent from Mirkwood
> 
> 
> --
> %(real_name)s Pentax-Discuss Mail List
> To unsubscribe send an email to pdml-le...@pdml.net
> to UNSUBSCRIBE from the PDML, please visit the link directly above and follow 
> the directions.
--
%(real_name)s Pentax-Discuss Mail List
To unsubscribe send an email to pdml-le...@pdml.net
to UNSUBSCRIBE from the PDML, please visit the link directly above and follow 
the directions.

[ovs-dev] [PATCH v2 2/2] python: ovsdb-idl: Use monitor_cond for _Server DB.

[Terry Wilson]

Unlike the C IDL code, the Python version still monitors the
_Server DB with "monitor" instead of "monitor_cond". This results
in receiving an entire Database row every time the "index" value
is updated which includes the 'schema' column. Using "monitor_cond"
will result in "update2" notifications which just include the
changed "index" value.

Unlike the C IDL, the Python IDL requires a SchemaHelper object
to instanitate the IDL, leaving it to the user of the library to
call "get_schema" themselves. Since the Python IDL did not have
support for retrieving the schema automatically and did not have
a state for doing so, instead of transitioning on an error response
from retrieving the _Server schema to requesting the "data" schema,
this moves directly to monitoring the "data" DB.

Signed-off-by: Terry Wilson 
---
 python/ovs/db/idl.py | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/python/ovs/db/idl.py b/python/ovs/db/idl.py
index a80da84e7..c1341fc2a 100644
--- a/python/ovs/db/idl.py
+++ b/python/ovs/db/idl.py
@@ -35,9 +35,9 @@ ROW_CREATE = "create"
 ROW_UPDATE = "update"
 ROW_DELETE = "delete"
 
-OVSDB_UPDATE = 0
-OVSDB_UPDATE2 = 1
-OVSDB_UPDATE3 = 2
+OVSDB_UPDATE = "update"
+OVSDB_UPDATE2 = "update2"
+OVSDB_UPDATE3 = "update3"
 
 CLUSTERED = "clustered"
 RELAY = "relay"
@@ -77,7 +77,7 @@ class ColumnDefaultDict(dict):
 return item in self.keys()
 
 
-class Monitor(enum.IntEnum):
+class Monitor(enum.Enum):
 monitor = OVSDB_UPDATE
 monitor_cond = OVSDB_UPDATE2
 monitor_cond_since = OVSDB_UPDATE3
@@ -465,23 +465,18 @@ class Idl(object):
 self.__parse_update(msg.params[2], OVSDB_UPDATE3)
 self.last_id = msg.params[1]
 elif (msg.type == ovs.jsonrpc.Message.T_NOTIFY
-and msg.method == "update2"
-and len(msg.params) == 2):
-# Database contents changed.
-self.__parse_update(msg.params[1], OVSDB_UPDATE2)
-elif (msg.type == ovs.jsonrpc.Message.T_NOTIFY
-and msg.method == "update"
+and msg.method in (OVSDB_UPDATE, OVSDB_UPDATE2)
 and len(msg.params) == 2):
 # Database contents changed.
 if msg.params[0] == str(self.server_monitor_uuid):
-self.__parse_update(msg.params[1], OVSDB_UPDATE,
+self.__parse_update(msg.params[1], msg.method,
 tables=self.server_tables)
 self.change_seqno = previous_change_seqno
 if not self.__check_server_db():
 self.force_reconnect()
 break
 else:
-self.__parse_update(msg.params[1], OVSDB_UPDATE)
+self.__parse_update(msg.params[1], msg.method)
 elif self.handle_monitor_canceled(msg):
 break
 elif self.handle_monitor_cancel_reply(msg):
@@ -540,7 +535,7 @@ class Idl(object):
 # Reply to our "monitor" of _Server request.
 try:
 self._server_monitor_request_id = None
-self.__parse_update(msg.result, OVSDB_UPDATE,
+self.__parse_update(msg.result, OVSDB_UPDATE2,
 tables=self.server_tables)
 self.change_seqno = previous_change_seqno
 if self.__check_server_db():
@@ -579,6 +574,11 @@ class Idl(object):
 elif msg.type == ovs.jsonrpc.Message.T_NOTIFY and msg.id == "echo":
 # Reply to our echo request.  Ignore it.
 pass
+elif (msg.type == ovs.jsonrpc.Message.T_ERROR and
+  self.state == self.IDL_S_SERVER_MONITOR_REQUESTED and
+  msg.id == self._server_monitor_request_id):
+self._server_monitor_request_id = None
+self.__send_monitor_request()
 elif (msg.type == ovs.jsonrpc.Message.T_ERROR and
   self.state == (
   self.IDL_S_DATA_MONITOR_COND_SINCE_REQUESTED) and
@@ -912,7 +912,7 @@ class Idl(object):
 monitor_request = {"columns": columns}
 monitor_requests[table.name] = [monitor_request]
 msg = ovs.jsonrpc.Message.create_request(
-'monitor', [self._server_db.name,
+'monitor_cond', [self._server_db.name,
  str(self.server_monitor_uuid),
  monitor_requests])
 self._server_monitor_request_id = msg.id
-- 
2.34.3

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH v2 1/2] ovsdb-idl: Add C IDL test for "monitor" fallback.

[Terry Wilson]

There was a Python-only test for ensuring that the library would
work when connecting to an older ovsdb-server that did not support
monitor_cond. This adds a C IDL version of that test.

Signed-off-by: Terry Wilson 
---
 tests/ovsdb-idl.at | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/tests/ovsdb-idl.at b/tests/ovsdb-idl.at
index c9e36d678..97162707e 100644
--- a/tests/ovsdb-idl.at
+++ b/tests/ovsdb-idl.at
@@ -1119,6 +1119,19 @@ OVSDB_CHECK_IDL_FETCH_COLUMNS([simple idl, initially 
populated],
 003: done
 ]])
 
+m4_define([OVSDB_CHECK_IDL_WO_MONITOR_COND_C],
+  [AT_SETUP([$1 - C])
+   AT_KEYWORDS([ovsdb server idl monitor $4])
+   OVSDB_START_IDLTEST
+   AT_CHECK([ovs-appctl -t ovsdb-server ovsdb-server/disable-monitor-cond])
+
+   AT_CHECK([test-ovsdb '-vPATTERN:console:test-ovsdb|%c|%m' -vjsonrpc -t10 
idl unix:socket $2],
+[0], [stdout], [ignore])
+   AT_CHECK([sort stdout | uuidfilt]m4_if([$5],,, [[| $5]]),
+[0], [$3])
+   OVSDB_SERVER_SHUTDOWN
+   AT_CLEANUP])
+
 m4_define([OVSDB_CHECK_IDL_WO_MONITOR_COND_PY],
   [AT_SETUP([$1 - Python3])
AT_KEYWORDS([ovsdb server idl Python monitor $4])
@@ -1132,7 +1145,8 @@ m4_define([OVSDB_CHECK_IDL_WO_MONITOR_COND_PY],
AT_CLEANUP])
 
 m4_define([OVSDB_CHECK_IDL_WO_MONITOR_COND],
-   [OVSDB_CHECK_IDL_WO_MONITOR_COND_PY($@)])
+   [OVSDB_CHECK_IDL_WO_MONITOR_COND_C($@)
+OVSDB_CHECK_IDL_WO_MONITOR_COND_PY($@)])
 
 
 OVSDB_CHECK_IDL_WO_MONITOR_COND([simple idl disable monitor-cond],
-- 
2.34.3

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH 0/2] python: ovsdb-idl Use monitor_cond for _Server DB.

[Terry Wilson]

Using "monitor" for _Server means that every bump to Database.index
sends a large "update"  notification containing a lot of data
including the Database schema text. This updates the Python IDL to
use "monitor_cond" as the C IDL does.

There is a difference in logic between the two IDL implementations.
Python IDL's Idl takes a SchemaHelper object as a required object
for instantiation, while the C IDL will transition through calling
"get_schema" on first the _Server DB and data DB if that errors out.
Although the Python version calls get_schema for _Server, it has
never called it on data, presumably because the schema is passed at
instantiation.

This implementation instead of adding support for getting and using
the schema via "get_schema" on the data db, transitions from an
error retreiving the schema from _Server to directly monitoring the
data DB (since we already were passed a schema at instantiation).

It would be good to, in the future, add support for not having to
specify the schema at Idl creation, but that kind of API change
should be done on its own (hopefully in a backward-compatible way).

Terry Wilson (2):
  ovsdb-idl: Add C IDL test for "monitor" fallback
  python: ovsdb-idl: Use monitor_cond for _Server DB

 python/ovs/db/idl.py | 28 ++--
 tests/ovsdb-idl.at   | 16 +++-
 2 files changed, 29 insertions(+), 15 deletions(-)

-- 
2.34.3

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [blink-dev] Intent to Ship: Tabbed web apps

[Brett Wilson]

On Mon, May 6, 2024 at 3:02 AM Yoav Weiss (@Shopify) 
wrote:

>
>
> On Fri, May 3, 2024 at 7:28 PM Brett Wilson  wrote:
>
>> Contact emailsbre...@chromium.org, alancut...@chromium.org,
>> mgi...@chromium.org, loubr...@google.com
>>
>> Explainer
>> https://github.com/WICG/manifest-incubations/blob/gh-pages/tabbed-mode-explainer.md
>>
>> Specificationhttps://wicg.github.io/manifest-incubations/#dfn-tabbed
>>
>> Summary
>>
>> Allow web app windows to have a tab strip. This adds a new display mode
>> "tabbed" and a new manifest field to allow customizations to the tab strip.
>>
>>
>> Blink componentBlink>AppManifest
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EAppManifest>
>>
>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/841
>>
>> TAG review statusIssues addressed
>>
>> Chromium Trial NameWebAppTabStrip
>>
>> Link to origin trial feedback summary
>> https://github.com/WICG/manifest-incubations/issues
>>
>> Origin Trial documentation link
>> https://github.com/WICG/manifest-incubations/blob/gh-pages/tabbed-mode-explainer.md
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>>
>>
>> *Gecko*: Defer (https://github.com/mozilla/standards-positions/issues/811
>> )
>>
>> *WebKit*: No signal (
>> https://github.com/WebKit/standards-positions/issues/195)
>>
>> *Web developers*: Positive (https://github.com/w3c/manifest/issues/737)
>>
>> *Other signals*:
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially high risk for Android WebView-based applications?
>>
>> N/A
>>
>>
>> Debuggability
>>
>> chrome://web-app-internals can be used for debugging, and the new
>> manifest field could also be added to the DevTools Application pane.
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, ChromeOS, Android, and Android WebView)?No
>>
>> The origin trial is available on ChromeOS only. Support for other desktop
>> platforms is planned.
>>
>>
>> Is this feature fully tested by web-platform-tests
>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>> ?Yes
>>
>>
>> https://github.com/web-platform-tests/wpt/tree/master/appmanifest/display-override-member
>>
>>
>> Flag name on chrome://flagschrome://flags/#enable-desktop-pwas-tab-strip
>>
>> Finch feature nameDesktopPWAsTabStrip
>>
>> Requires code in //chrome?True
>>
>> Tracking bughttps://issuetracker.google.com/issues/40598974
>>
>> Launch bughttps://launch.corp.google.com/launch/4253814
>>
>> MeasurementLaunch.WebAppDisplayMode: Tabbed
>>
>> Availability expectationFeature is available only on Chrome-on-ChromeOS
>> for the foreseeable future.
>>
>
> This seems a bit contradictory with "Support for other desktop platforms
> is planned" above. Are there plans for support beyond CrOS?
>
>>
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABiGVV9MstA8bLmUTLkkfTjeYK8bb7fkhyKL_OMt_d7UzavRTA%40mail.gmail.com?utm_medium=email_source=footer>
>
>
Sorry, the first part was a mistake. Chrome team has requested this not be
on other platforms now.

Brett

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABiGVV8N3PxBDPFGkE5M_-g22qWnQGhNq3sd%2BDxCgCmCN%3DS4Xg%40mail.gmail.com.

[ovs-dev] [PATCH 2/2] python: ovsdb-idl: Use monitor_cond for _Server DB

[Terry Wilson]

Unlike the C IDL code, the Python version still monitors the
_Server DB with "monitor" instead of "monitor_cond". This results
in receiving an entire Database row every time the "index" value
is updated which includes the 'schema' column. Using "monitor_cond"
will result in "update2" notifications which just include the
changed "index" value.

Unlike the C IDL, the Python IDL requires a SchemaHelper object
to instanitate the IDL, leaving it to the user of the library to
call "get_schema" themselves. Since the Python IDL did not have
support for retrieving the schema automatically and did not have
a state for doing so, instead of transitioning on an error response
from retrieving the _Server schema to requesting the "data" schema,
this moves directly to monitoring the "data" DB.

Signed-off-by: Terry Wilson 
---
 python/ovs/db/idl.py | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/python/ovs/db/idl.py b/python/ovs/db/idl.py
index a80da84e7..c1341fc2a 100644
--- a/python/ovs/db/idl.py
+++ b/python/ovs/db/idl.py
@@ -35,9 +35,9 @@ ROW_CREATE = "create"
 ROW_UPDATE = "update"
 ROW_DELETE = "delete"
 
-OVSDB_UPDATE = 0
-OVSDB_UPDATE2 = 1
-OVSDB_UPDATE3 = 2
+OVSDB_UPDATE = "update"
+OVSDB_UPDATE2 = "update2"
+OVSDB_UPDATE3 = "update3"
 
 CLUSTERED = "clustered"
 RELAY = "relay"
@@ -77,7 +77,7 @@ class ColumnDefaultDict(dict):
 return item in self.keys()
 
 
-class Monitor(enum.IntEnum):
+class Monitor(enum.Enum):
 monitor = OVSDB_UPDATE
 monitor_cond = OVSDB_UPDATE2
 monitor_cond_since = OVSDB_UPDATE3
@@ -465,23 +465,18 @@ class Idl(object):
 self.__parse_update(msg.params[2], OVSDB_UPDATE3)
 self.last_id = msg.params[1]
 elif (msg.type == ovs.jsonrpc.Message.T_NOTIFY
-and msg.method == "update2"
-and len(msg.params) == 2):
-# Database contents changed.
-self.__parse_update(msg.params[1], OVSDB_UPDATE2)
-elif (msg.type == ovs.jsonrpc.Message.T_NOTIFY
-and msg.method == "update"
+and msg.method in (OVSDB_UPDATE, OVSDB_UPDATE2)
 and len(msg.params) == 2):
 # Database contents changed.
 if msg.params[0] == str(self.server_monitor_uuid):
-self.__parse_update(msg.params[1], OVSDB_UPDATE,
+self.__parse_update(msg.params[1], msg.method,
 tables=self.server_tables)
 self.change_seqno = previous_change_seqno
 if not self.__check_server_db():
 self.force_reconnect()
 break
 else:
-self.__parse_update(msg.params[1], OVSDB_UPDATE)
+self.__parse_update(msg.params[1], msg.method)
 elif self.handle_monitor_canceled(msg):
 break
 elif self.handle_monitor_cancel_reply(msg):
@@ -540,7 +535,7 @@ class Idl(object):
 # Reply to our "monitor" of _Server request.
 try:
 self._server_monitor_request_id = None
-self.__parse_update(msg.result, OVSDB_UPDATE,
+self.__parse_update(msg.result, OVSDB_UPDATE2,
 tables=self.server_tables)
 self.change_seqno = previous_change_seqno
 if self.__check_server_db():
@@ -579,6 +574,11 @@ class Idl(object):
 elif msg.type == ovs.jsonrpc.Message.T_NOTIFY and msg.id == "echo":
 # Reply to our echo request.  Ignore it.
 pass
+elif (msg.type == ovs.jsonrpc.Message.T_ERROR and
+  self.state == self.IDL_S_SERVER_MONITOR_REQUESTED and
+  msg.id == self._server_monitor_request_id):
+self._server_monitor_request_id = None
+self.__send_monitor_request()
 elif (msg.type == ovs.jsonrpc.Message.T_ERROR and
   self.state == (
   self.IDL_S_DATA_MONITOR_COND_SINCE_REQUESTED) and
@@ -912,7 +912,7 @@ class Idl(object):
 monitor_request = {"columns": columns}
 monitor_requests[table.name] = [monitor_request]
 msg = ovs.jsonrpc.Message.create_request(
-'monitor', [self._server_db.name,
+'monitor_cond', [self._server_db.name,
  str(self.server_monitor_uuid),
  monitor_requests])
 self._server_monitor_request_id = msg.id
-- 
2.34.3

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH 1/2] ovsdb-idl: Add C IDL test for "monitor" fallback

[Terry Wilson]

There was a Python-only test for ensuring that the library would
work when connecting to an older ovsdb-server that did not support
monitor_cond. This adds a C IDL version of that test.

Signed-off-by: Terry Wilson 
---
 tests/ovsdb-idl.at | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/tests/ovsdb-idl.at b/tests/ovsdb-idl.at
index fb568dd82..a8df11ac4 100644
--- a/tests/ovsdb-idl.at
+++ b/tests/ovsdb-idl.at
@@ -1119,6 +1119,19 @@ OVSDB_CHECK_IDL_FETCH_COLUMNS([simple idl, initially 
populated],
 003: done
 ]])
 
+m4_define([OVSDB_CHECK_IDL_WO_MONITOR_COND_C],
+  [AT_SETUP([$1 - C])
+   AT_KEYWORDS([ovsdb server idl monitor $4])
+   OVSDB_START_IDLTEST
+   AT_CHECK([ovs-appctl -t ovsdb-server ovsdb-server/disable-monitor-cond])
+
+   AT_CHECK([test-ovsdb '-vPATTERN:console:test-ovsdb|%c|%m' -vjsonrpc -t10 
idl unix:socket $2],
+[0], [stdout], [ignore])
+   AT_CHECK([sort stdout | uuidfilt]m4_if([$5],,, [[| $5]]),
+[0], [$3])
+   OVSDB_SERVER_SHUTDOWN
+   AT_CLEANUP])
+
 m4_define([OVSDB_CHECK_IDL_WO_MONITOR_COND_PY],
   [AT_SETUP([$1 - Python3])
AT_KEYWORDS([ovsdb server idl Python monitor $4])
@@ -1132,7 +1145,8 @@ m4_define([OVSDB_CHECK_IDL_WO_MONITOR_COND_PY],
AT_CLEANUP])
 
 m4_define([OVSDB_CHECK_IDL_WO_MONITOR_COND],
-   [OVSDB_CHECK_IDL_WO_MONITOR_COND_PY($@)])
+   [OVSDB_CHECK_IDL_WO_MONITOR_COND_C($@)
+OVSDB_CHECK_IDL_WO_MONITOR_COND_PY($@)])
 
 
 OVSDB_CHECK_IDL_WO_MONITOR_COND([simple idl disable monitor-cond],
-- 
2.34.3

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH 0/2] python: ovsdb-idl Use monitor_cond for _Server DB

[Terry Wilson]

Using "monitor" for _Server means that every bump to Database.index
sends a large "update"  notification containing a lot of data
including the Database schema text. This updates the Python IDL to
use "monitor_cond" as the C IDL does.

There is a difference in logic between the two IDL implementations.
Python IDL's Idl takes a SchemaHelper object as a required object
for instantiation, while the C IDL will transition through calling
"get_schema" on first the _Server DB and data DB if that errors out.
Although the Python version calls get_schema for _Server, it has
never called it on data, presumably because the schema is passed at
instantiation.

This implementation instead of adding support for getting and using
the schema via "get_schema" on the data db, transitions from an
error retreiving the schema from _Server to directly monitoring the
data DB (since we already were passed a schema at instantiation).

It would be good to, in the future, add support for not having to
specify the schema at Idl creation, but that kind of API change
should be done on its own (hopefully in a backward-compatible way).

Terry Wilson (2):
  ovsdb-idl: Add C IDL test for "monitor" fallback
  python: ovsdb-idl: Use monitor_cond for _Server DB

 python/ovs/db/idl.py | 28 ++--
 tests/ovsdb-idl.at   | 16 +++-
 2 files changed, 29 insertions(+), 15 deletions(-)

-- 
2.34.3

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [Servercert-wg] [Voting Begins] Ballot SC-74 - Clarify CP/CPS structure according to RFC 3647

[Ben Wilson via Servercert-wg]

Mozilla votes "yes" on Ballot SC-74.

On Sun, May 5, 2024 at 3:06 AM Dimitris Zacharopoulos (HARICA) via
Servercert-wg  wrote:

> HARICA votes "yes" to ballot SC-74.
>
> On 5/5/2024 11:24 π.μ., Dimitris Zacharopoulos (HARICA) via Servercert-wg
> wrote:
>
> Voting begins for ballot SC-74.
> SC-74 - Clarify CP/CPS structure according to RFC 3647 Summary
>
> The TLS Baseline Requirements require in section 2.2 that:
>
> *"The Certificate Policy and/or Certification Practice Statement MUST be
> structured in accordance with RFC 3647 and MUST include all material
> required by RFC 3647."*
>
> The intent of this language was to ensure that all CAs' CP and/or CPS
> documents contain a similar structure, making it easier to review and
> compare against the BRs. However, there was some ambiguity as to the actual
> structure that CAs should follow. After several discussions in the SCWG
> Public Mailing List
> 
> and F2F meetings, it was agreed that more clarity should be added to the
> existing requirement, pointing to the outline described in section 6 of RFC
> 3647.
>
> The following motion has been proposed by Dimitris Zacharopoulos (HARICA)
> and endorsed by Aaron Poulsen (Amazon) and Tim Hollebeek (Digicert).
>
> You can view the github pull request representing this ballot here
> .
> Motion Begins
>
> MODIFY the "Baseline Requirements for the Issuance and Management of
> Publicly-Trusted TLS Server Certificates" based on Version 2.0.4 as
> specified in the following redline:
>
>-
>
> https://github.com/cabforum/servercert/compare/c4a34fe2292022e0a04ba66b5a85df75907ac2a2...f6a90e2a652fbb7a2d62a976b70f4af3adce8dae
>
> Motion Ends
>
> This ballot proposes a Final Maintenance Guideline. The procedure for
> approval of this ballot is as follows:
> Discussion (at least 7 days)
>
>- Start time: 2024-04-25 16:30:00 UTC
>- End time: on or after 2024-05-02 16:30:00 UTC
>
> Vote for approval (7 days)
>
>- Start time: 2024-05-05 8:30:00 UTC
>- End time: 2024-05-12 8:30:00 UTC
>
>
>
> ___
> Servercert-wg mailing 
> listServercert-wg@cabforum.orghttps://lists.cabforum.org/mailman/listinfo/servercert-wg
>
>
> ___
> Servercert-wg mailing list
> Servercert-wg@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

Re: [go-cd] pipeline as code - stuck on waiting for agent

[Chad Wilson]

Perhaps you can share the agent(s) you are expecting it to run on, and the
job configuration of the jobs that aren't scheduling?

If the job isn't being assigned, it means there is no free agent[1] in the
desired pipeline-scope environment[2] that offers the requested job-scope
resources [3]. All three conditions need to be met, so either your agent or
the pipeline/job may be configured in a different way to your agents
(perhaps it is requesting a "resource")?

Keep in mind that you don't have to use job resource requirements or
environments if you don't want to, and you can configure it such that some
agents will be able to run jobs with no specific requested resource; or no
specific environment.

-Chad

On Sat, May 4, 2024 at 1:10 AM 'pan...@mammoth.io' via go-cd <
go-cd@googlegroups.com> wrote:

> Hi,
>
> I am trying to use the feature of pipeline as a code. In the config
> repository, I have configured an Allow rule for a specific environment.
> There are agents assigned to this environment. Having done this, I am now
> triggering the pipeline. The pipeline however just keeps waiting for an
> agent allocation. What step am I missing and where should this be
> configured.
> [image: Screenshot from 2024-05-03 22-38-39.png]
>
> Any help would be appreciated.
>
> Warm regards,
> Pankaj
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "go-cd" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to go-cd+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/go-cd/a19f5206-b9e3-4321-9831-e3da5fdf4c92n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"go-cd" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to go-cd+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/go-cd/CAA1RwH9MsLA31XJ0HpS9s0Fw15owYt8x6r61JmpqLpoUx-RP%2Bw%40mail.gmail.com.

[ktorrent] [Bug 283335] UPNP gives 'internal server error' in 'port forwarded' column since upgrade to 4.7.x

[Steven V. Wilson]

https://bugs.kde.org/show_bug.cgi?id=283335

Steven V. Wilson  changed:

   What|Removed |Added

 CC||funmaker...@yahoo.com

--- Comment #5 from Steven V. Wilson  ---
This bug appears to have returned. Please reopen it. Kubuntu 23.04 Ktorrent
version 23.08.1 Thanks.

-- 
You are receiving this mail because:
You are watching all bug changes.

[spectre] Apply Now: MA Spiel und Objekt

[Hannah Perner-Wilson via SPECTRE]

Dear friends and colleagues,

The MA studio Spiel und Objekt provides time and space for experimenting with 
new aesthetics in theatrical storytelling, while learning the fundamental 
skills and technical knowledge for staging interactive theatrical processes.

We’re entering the fourth round, and look forward to receiving applications for 
our next cohort! 
The application period is from 11.03. to 14.05.2024. 
Please consider applying, and/or forwarding this information 
 to anyone who could be 
interested.

Further information on applications can be found on our program’s website 
www.spielundobjekt.de  

Greetings:-)
Hannah && Clemens

_
Spiel und Objekt
Hochschule für Schauspielkunst Ernst Busch
spielundobj...@hfs-berlin.de 
https://spielundobjekt.de/ 
https://www.hfs-berlin.de/ 
https://www.instagram.com/spiel_und_objekt/ 
__
SPECTRE list for media culture in Deep Europe
Info, archive and help:
http://post.in-mind.de/cgi-bin/mailman/listinfo/spectre

[blink-dev] Intent to Ship: Tabbed web apps

[Brett Wilson]

Contact emailsbre...@chromium.org, alancut...@chromium.org,
mgi...@chromium.org, loubr...@google.com

Explainer
https://github.com/WICG/manifest-incubations/blob/gh-pages/tabbed-mode-explainer.md

Specificationhttps://wicg.github.io/manifest-incubations/#dfn-tabbed

Summary

Allow web app windows to have a tab strip. This adds a new display mode
"tabbed" and a new manifest field to allow customizations to the tab strip.


Blink componentBlink>AppManifest


TAG reviewhttps://github.com/w3ctag/design-reviews/issues/841

TAG review statusIssues addressed

Chromium Trial NameWebAppTabStrip

Link to origin trial feedback summary
https://github.com/WICG/manifest-incubations/issues

Origin Trial documentation link
https://github.com/WICG/manifest-incubations/blob/gh-pages/tabbed-mode-explainer.md

Risks


Interoperability and Compatibility



*Gecko*: Defer (https://github.com/mozilla/standards-positions/issues/811)

*WebKit*: No signal (
https://github.com/WebKit/standards-positions/issues/195)

*Web developers*: Positive (https://github.com/w3c/manifest/issues/737)

*Other signals*:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that
it has potentially high risk for Android WebView-based applications?

N/A


Debuggability

chrome://web-app-internals can be used for debugging, and the new manifest
field could also be added to the DevTools Application pane.


Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, ChromeOS, Android, and Android WebView)?No

The origin trial is available on ChromeOS only. Support for other desktop
platforms is planned.


Is this feature fully tested by web-platform-tests

?Yes

https://github.com/web-platform-tests/wpt/tree/master/appmanifest/display-override-member


Flag name on chrome://flagschrome://flags/#enable-desktop-pwas-tab-strip

Finch feature nameDesktopPWAsTabStrip

Requires code in //chrome?True

Tracking bughttps://issuetracker.google.com/issues/40598974

Launch bughttps://launch.corp.google.com/launch/4253814

MeasurementLaunch.WebAppDisplayMode: Tabbed

Availability expectationFeature is available only on Chrome-on-ChromeOS for
the foreseeable future.

Adoption expectationFeature is used by specific partner(s) to provide
functionality within 12 months of launch in Chrome. May be of interest to a
handful of PWA authors primarily in the productivity space.

Adoption planWorking with a small number of partners directly.

Non-OSS dependencies

Does the feature depend on any code or APIs outside the Chromium open
source repository and its open-source dependencies to function?
N/A

Sample links
https://paint-rightful-patch.glitch.me

Estimated milestones
Shipping on desktop 126
Origin trial desktop first 118
Origin trial desktop last 126
Origin trial extension 1 end milestone 126

Anticipated spec changes

Open questions about a feature may be a source of future web compat or
interop issues. Please list open issues (e.g. links to known github issues
in the project for the feature specification) whose resolution may
introduce web compat/interop risk (e.g., changing to naming or structure of
the API in a non-backward-compatible way).
Chromium implementation currently does not parse string-form URL patterns
as required by the spec. Marked "at risk". (
https://github.com/WICG/manifest-incubations/issues/97)

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5128143454076928?gate=6176288199409664

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/g/blink-dev/c/IvfIkjvQYuY/m/cixwOyEeAAAJ
Intent
to Experiment:
https://groups.google.com/a/chromium.org/g/blink-dev/c/m16m2TEq-NM/m/0Bc10numCgAJ
Intent to Extend Experiment 1:
https://groups.google.com/a/chromium.org/g/blink-dev/c/5aRDL-E9olQ/m/Pb7ECdcpAAAJ
Intent to Ship:
https://groups.google.com/a/chromium.org/g/blink-dev/c/5aRDL-E9olQ/m/Pb7ECdcpAAAJ


This intent message was generated by Chrome Platform Status
.

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABiGVV9MstA8bLmUTLkkfTjeYK8bb7fkhyKL_OMt_d7UzavRTA%40mail.gmail.com.

Re: [Metamath] Question abouot indistopon

['B. Wilson' via Metamath]

Thank you for the pointer, Mario. Is this negative vs. positive position
terminology something you neologized on the fly? Or does it have precedent? If
I'm grokking you correctly, the positive positions plug into the negative
positions, which jibes with your explanation and the Is-a-set convention you
reference.

Thanks for the clarity.


Mario Carneiro  wrote:
> There is a convention, which is to use "( A e. V -> ..." in antecedents to
> theorems and deduction-form statements and |- A e. _V in inference-form
> theorems. In "positive position", you often need to use A e. _V, i.e. in
> fvex there is no other reasonable option for what set to say that function
> value is a member of without any assumptions. In "negative position", it's
> a question of whether to spend one extra elex step in some cases (e.g. 2 e.
> RR therefore 2 e. _V therefore I can apply this lemma about sets to 2), or
> one extra syntax step to instantiate the V argument (which also takes some
> space in proofs). I believe the above convention is derived from some
> analysis along these lines, but it's also somewhat historical (it's more
> important to have a consistent convention). See the "Is-a-set." section of
> https://us.metamath.org/mpeuni/conventions.html for more information.
> 
> On Wed, Apr 24, 2024 at 3:52 AM heiphohmia via Metamath <
> metamath@googlegroups.com> wrote:
> 
> > > It functions much like A e. _V would. A proof using this theorem can
> > always
> > > plug in _V for V but it also could plug in On, RR, or whatever is
> > convenient.
> > > Perhaps looking at  makes it
> > clear.
> >
> > Okay, elements of ZF classes are always sets, so A e. V restricts A from
> > being
> > proper classes. That begs the question why one would ever use A e. _V
> > though.
> > Is this just a case where there's no particular convention?
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Metamath" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to metamath+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> > https://groups.google.com/d/msgid/metamath/272R9VKF3UZLE.34NMDVUCB3A1P%40wilsonb.com
> > .
> >


-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/2VC9HKX4Q39T0.1ZIJO4RNZ5BIT%40wilsonb.com.

Re: [Infrastructure] Google doc for the CABF Handbook

[Ben Wilson via Infrastructure]

I've updated this some more:
https://docs.google.com/document/d/1GfisFGuFKFeY4kHr08zsQks1GwpRVyn2Gl6-eGSDmOw/edit

On Thu, Mar 21, 2024 at 4:12 AM Inigo Barreira via Infrastructure <
infrastructure@cabforum.org> wrote:

> Hi all,
>
>
>
> See this link:
> https://docs.google.com/document/d/1GfisFGuFKFeY4kHr08zsQks1GwpRVyn2Gl6-eGSDmOw/edit?usp=sharing
>
>
>
> It´s a Google doc with what was shared initially in the email. It´s just a
> very first draft of a framework with the basics to handle to all
> new/old/potential responsible people in order to have it all in on document
> and organized.
>
> Some of these sections are already covered and some maybe need
> adjustments/updates/clarifications. Feel free to add anything that is
> correct and move the document where you think suits better.
>
>
>
> Regards
> ___
> Infrastructure mailing list
> Infrastructure@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/infrastructure
>
___
Infrastructure mailing list
Infrastructure@cabforum.org
https://lists.cabforum.org/mailman/listinfo/infrastructure

Re: [Servercert-wg] [External Sender] Question regarding the id-ad-caIssuers accessMethod URI

[Clint Wilson via Servercert-wg]

I did a quick check, but was only able to find one recently issued leaf 
certificate that contained an https CA Issuers URI. There seems to be about 26 
CA certificates that do as well, but all were issued before 2019 except for 2. 
Of the 1 leaf and 2 CA certificates that are more recent, they’re all from CAs 
that have very limited root inclusion in the ecosystem and do not participate 
in the CA/BF afaict.

Not sure how relevant all that is, but just to share what I’d found. I’m sure 
others could do a more thorough job, but I don’t see clear signs that this is a 
widespread issue at least (phew! :)

Cheers,
-Clint

> On Apr 30, 2024, at 11:40 PM, Dimitris Zacharopoulos (HARICA) 
>  wrote:
> 
> Thanks Clint,
> 
> It would help doing some research in CENSYS to see if this is a real problem 
> or not. I will try to get some additional resources internally to help me 
> with this. In any case, this discussion might inspire some of the linting 
> software developers to write a lint expecting only http:// URLs in that field.
> 
> 
> Best regards,
> Dimitris.
> 
> On 1/5/2024 12:52 π.μ., Clint Wilson wrote:
>> Hi Dimitris,
>> 
>> My understanding is that the intent was indeed to restrict these to HTTP 
>> specifically. That is, the phrase “the only URLS present MUST be HTTP URLs” 
>> is intended to preclude the use of HTTPS, and not just to indicate that any 
>> scheme which relies on the Hypertext Transfer Protocol can be used.
>> 
>> Presumably when 5280 was drafted, the authors were aware of the updates 2817 
>> made to 2616, but chose not to reference those updates. Even if not, I 
>> concur with Ryan and my recollection is also that the discussion during 
>> SC-62’s formation did include this topic with the consensus (at that time) 
>> being that some fields would be restricted to using only HTTP URIs.
>> 
>> To your original questions:
>>>>>> Do Members agree with that interpretation? 
>> 
>> Yes
>> 
>>>>>> 
>>>>>> If this is the correct interpretation, would it be considered a 
>>>>>> violation of the BRs if a CA or end-entity certificate contains https:// 
>>>>>> URL in the id-ad-caIssuers accessMethod ? 
>> 
>> Yes, at least for certificates issued after SC-62 went into effect (maybe 
>> also for those prior, I just haven’t looked).
>> 
>>>>>> 
>>>>>> I'm afraid that this might not be as clear in the BRs as it should be, 
>>>>>> so if people agree with the above, we should probably update section 
>>>>>> 7.1.2.7.7 
>>>>>> <https://github.com/cabforum/servercert/blob/main/docs/BR.md#71277-subscriber-certificate-authority-information-access>
>>>>>>  (and possibly other parts) to explicitly state that the allowed scheme 
>>>>>> is "http" and not "https", just like we do for the CRLDP in section 
>>>>>> 7.1.2.11.2 
>>>>>> <https://github.com/cabforum/servercert/blob/main/docs/BR.md#712112-crl-distribution-points>
>>>>>>  . 
>> 
>> I’m not convinced a clarification is worthwhile here. To be clear, I’m not 
>> opposed, I’m just not sure it’s something CAs are actively getting or likely 
>> to get wrong — if some are, then I would instead support such a 
>> clarification.
>> 
>> Cheers!
>> -Clint
>> 
>>> On Apr 25, 2024, at 5:41 AM, Dimitris Zacharopoulos (HARICA) via 
>>> Servercert-wg  
>>> <mailto:servercert-wg@cabforum.org> wrote:
>>> 
>>> Hi Ryan,
>>> 
>>> The question is not between HTTP vs FTP vs LDAP but specifically for "HTTP 
>>> URL" that could have two schemes "http" and "https".
>>> 
>>> RFC 2616 (June 1999) included only "http" and was updated in May 2000 by 
>>> RFC 2817 <https://datatracker.ietf.org/doc/html/rfc2817> to include TLS 
>>> Within HTTP/1.1 ("https").
>>> 
>>> I hope this clarifies the issue.
>>> 
>>> 
>>> Dimitris.
>>> 
>>> On 25/4/2024 3:29 μ.μ., Ryan Dickson via Servercert-wg wrote:
>>>> It's my understanding that the intent of the updates made in SC-62 were to 
>>>> prohibit any non-HTTP URI. This was discussed in:
>>>> 
>>>> 1) at least one historical GitHub discussion 
>>>> <https://github.com/sleevi/cabforum-docs/pull/36> (referenced in ballot 
>>>> preamble 
>>>> <https://cabforum.org/2023/03/17/ballot-sc62v2-certificate-profile

Re: [Goanet] Fr. MARDEN PEREIRA prefect at GAHS Curchorem

[Wilson Soares]

I know Fr Marden during my time in Guardian Angel in 1973 onwards. I would like 
to visit him but I'm only coming down in November. God have Mercy on him and 
keep him longer then my visit to Goa.

Yahoo Mail: Search, Organize, Conquer 
 
  On Tue, Apr 30, 2024 at 9:06 p.m., Nelson Lopes 
wrote:   Rev Fr. MARDEN PEREIRA. Prefect at GAHS  Curchorem.  Served many 
fruitful
years in Northen India
He was a very  good soccer player  and drinbler of repute.An outstanding
social trait  was that he visited his students residences  , whenever he
was in Goa . This unique gesture  won him affection of  lasting friends.It
was indeed and exercise of love ,interest and concern. It is a very  rare
exercise  of keeping in touch with past students just to keep relations
WARM.I  know not of  any teacher ,who enjoyed this laborious exercise of
home visits  by public bus service
Now he is immobilized  due to advancing age at home in Pilar.He is losing
his memory but otherwise hale and hearty  as ever.It is now our turn to
visit him and give him the comfort and joy  of being wanted  and worthy of
being remembered. Do it before it is too late Tomorrow  is another  day His
interests in students and home visits is phenomenal

Nelson Lopes
Chinchinim
https://lopesnelsonnat.wordpress.com
  

[Metamath] Mnemonic of Fr

['B. Wilson' via Metamath]

This has been bugging me midly for a while, but I couldn't figure out what the
Fr symbol in df-fr stood for:

19201 df-fr $a |- ( R Fr A <-> A. x ( ( x C_ A /\ x =/= (/) ) -> E. y e. x 
A. z e. x -. z R y ) ) $.

I finally bothered to look up the Takeuti and Zaring reference, which also uses
"Fr" and calls R a "foundational relation". It's not super important, but would
it be worth mentioning this in df-fr's comment?

Cheers,
B. Wilson

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/2F5KIFFJJY2KH.28Z6N87TP90O2%40wilsonb.com.

[cabf_netsec] Voting Results of Ballot NS-003: Restructure the NCSSRs

[Clint Wilson via Netsec]

Voting Results of Ballot NS-003: Restructure the NCSSRs
The voting period for Ballot NS-003: Restructure the NCSSRs has ended and the 
Ballot has Passed. The following votes were cast:
4 votes by Certificate Consumers
4 Yes votes: Apple, Google, Microsoft, Mozilla 
0 No votes: 
0 Abstain votes: 
100% of voting Certificate Consumers voted in favor
18 votes by Certificate Issuers
18 Yes votes: Amazon Trust Services, Buypass, Chunghwa Telecom, Disig, Fastly, 
GDCA, GlobalSign, GoDaddy, HARICA, Kamu SM, OISTE, Sectigo, SSL.com, SwissSign, 
Telia Company, TrustAsia, TWCA, VikingCloud
0 No votes: 
0 Abstain votes: 
100% of voting Certificate Issuers voted in favor
Bylaw Requirements
Bylaw 2.3(6) requires:
a "yes" vote by two-thirds of Certificate Issuer votes and 50%-plus-one 
Certificate Consumer votes for approval.  Votes to abstain are not counted for 
this purpose. 
This requirement was met for both Certificate Issuers and Certificate Consumers.
at least one Certificate Issuer and one Certificate Consumer Member must vote 
in favor of a ballot for the ballot to be adopted. 
This requirement was met for both Certificate Issuers and Certificate Consumers.
Bylaw 2.3(7) requires:
a ballot result will be considered valid only when more than half of the number 
of currently active Members has participated”. Votes to abstain are counted in 
determining a quorum. 
Half of currently active Members as of the start of voting was 7, so quorum was 
8 votes
22 votes were received
This requirement was met.

smime.p7s
Description: S/MIME cryptographic signature
___
Netsec mailing list
Netsec@cabforum.org
https://lists.cabforum.org/mailman/listinfo/netsec

Re: [Servercert-wg] [EXTERNAL] Re: Discussion Period Begins - Ballot SC-071: Subscriber Agreement and Terms of Use Consolidation

[Ben Wilson via Servercert-wg]

All,

I am currently looking at this version in Gitub:
https://github.com/cabforum/servercert/blob/SC-71/docs/BR.md. But I'm a
little confused on whether some of the recently suggested changes have been
merged into that version.

I'll defer to Dustin on whether Bruce's first suggestion for "Subscriber
Agreement" in BR section 9.6.1 should replace the second, less preferable,
option.

Finally, re: the wording for the effective date, which I didn't like*, what
if it said something like this instead?

Prior to 2025-03-15, CAs may continue to refer to and utilize the phrase
"Terms of Use" as defined in the previous version of these Requirements
within their CP and CPS documents. Effective 2025-03-15, CAs shall replace
references to "Terms of Use" with "Subscriber Agreement" in their CP and
CPS documents. This change does not preclude the inclusion of "terms of
use" and other necessary terms and conditions within broader CA operational
documents, provided they are consistent with these Requirements

Feel free to edit as you see fit.

* My concern with the previously proposed language was that the first
sentence was too broad in that it didn't specify the context in which
"Terms of Use" might already be used, and similarly, my concern with the
second sentence was that it was overly broad in prohibiting all uses of
"Terms of Use" whatsoever.

Ben

On Tue, Apr 30, 2024 at 2:13 PM Bruce Morton 
wrote:

> Hi Ben,
>
>
>
> We have some feedback from our legal team.
>
>
>
> First suggestion is to simplify the change to only address the objectives
> of the ballot:
>
> 5. Subscriber Agreement: That, if the CA and Subscriber are not
> Affiliated, the Subscriber and CA are parties to a legally valid and
> enforceable Subscriber Agreement that satisfies these Requirements, or, if
> the CA and Subscriber are the same entity or are Affiliated, the Applicant
> Representative has accepted the Subscriber Agreement;
>
>
>
> Alternative (less preferable) option, accepts additional warranties that
> are superfluous to the objectives of the ballot, but fixes the legal
> impossibility of the last item (iii):
>
> 5. Subscriber Agreement: That,
>
> i. the Subscriber has access to the most current version of the Subscriber
> Agreement, which is posted to the CA’s policy document repository or has
> been provided through other means;
>
> ii. the applicable Subscriber Agreement is the Subscriber Agreement that
> was in force when the Certificate was issued; and
>
> iii. if the CA and Subscriber are not Affiliated, the Subscriber and CA
>  are parties to a legally valid and enforceable Subscriber Agreement that
> satisfies these Requirements, or, if the CA and Subscriber are the same
> entity or are Affiliated, the Applicant Representative has accepted the
> Subscriber Agreement;
>
>
>
>
>
> Thanks, Bruce.
>
>
>
> *From:* Servercert-wg  *On Behalf Of *Ben
> Wilson via Servercert-wg
> *Sent:* Wednesday, April 24, 2024 3:06 AM
> *To:* Wayne Thayer 
> *Cc:* CA/B Forum Server Certificate WG Public Discussion List <
> servercert-wg@cabforum.org>
> *Subject:* Re: [Servercert-wg] [EXTERNAL] Re: Discussion Period Begins -
> Ballot SC-071: Subscriber Agreement and Terms of Use Consolidation
>
>
>
> I removed it because I didn't like the phrasing. I can propose other
> wording for an effective date, unless anyone else wants to take a crack at
> it. On Wed, Apr 24, 2024, 1: 59 AM Wayne Thayer 
> wrote: Thanks Ben!The
>
> I removed it because I didn't like the phrasing. I can propose other
> wording for an effective date, unless anyone else wants to take a crack at
> it.
>
>
>
> On Wed, Apr 24, 2024, 1:59 AM Wayne Thayer  wrote:
>
> Thanks Ben!
>
>
>
> The second commit you linked removes the effective date for CP/CPS updates
> from section 9.6.3. While I'm not convinced that this is necessary, it
> seems to add some clarity. Was that paragraph meant to remain in place? If
> not, what is the reasoning?
>
>
>
> Otherwise I am also happy with these changes.
>
>
>
> - Wayne
>
>
>
> On Tue, Apr 23, 2024 at 4:21 PM Aaron Gable via Servercert-wg <
> servercert-wg@cabforum.org> wrote:
>
> Hi Ben,
>
>
>
> Thank you! I believe those combine with the previous commits to produce
> this redline, which looks good to me:
>
> https://github.com/cabforum/servercert/compare/41f01640748fa612386f8b1a3031cd1bff3d4f35...682488a832db5b6b4fcdd4cd7cbd86ae9541453e
> <https://urldefense.com/v3/__https:/github.com/cabforum/servercert/compare/41f01640748fa612386f8b1a3031cd1bff3d4f35...682488a832db5b6b4fcdd4cd7cbd86ae9541453e__;!!FJ-Y8qCqXTj2!c-eKDU27xX1FU55g2nJgccUKbM9SvUI7wCrdCc8dTazyEHAuWyMH8

Re: [Servercert-wg] [External Sender] Question regarding the id-ad-caIssuers accessMethod URI

[Clint Wilson via Servercert-wg]

Hi Dimitris,

My understanding is that the intent was indeed to restrict these to HTTP 
specifically. That is, the phrase “the only URLS present MUST be HTTP URLs” is 
intended to preclude the use of HTTPS, and not just to indicate that any scheme 
which relies on the Hypertext Transfer Protocol can be used.

Presumably when 5280 was drafted, the authors were aware of the updates 2817 
made to 2616, but chose not to reference those updates. Even if not, I concur 
with Ryan and my recollection is also that the discussion during SC-62’s 
formation did include this topic with the consensus (at that time) being that 
some fields would be restricted to using only HTTP URIs.

To your original questions:
 Do Members agree with that interpretation? 

Yes

 
 If this is the correct interpretation, would it be considered a violation 
 of the BRs if a CA or end-entity certificate contains https:// URL in the 
 id-ad-caIssuers accessMethod ? 

Yes, at least for certificates issued after SC-62 went into effect (maybe also 
for those prior, I just haven’t looked).

 
 I'm afraid that this might not be as clear in the BRs as it should be, so 
 if people agree with the above, we should probably update section 
 7.1.2.7.7 
 
  (and possibly other parts) to explicitly state that the allowed scheme is 
 "http" and not "https", just like we do for the CRLDP in section 
 7.1.2.11.2 
 
  . 

I’m not convinced a clarification is worthwhile here. To be clear, I’m not 
opposed, I’m just not sure it’s something CAs are actively getting or likely to 
get wrong — if some are, then I would instead support such a clarification.

Cheers!
-Clint

> On Apr 25, 2024, at 5:41 AM, Dimitris Zacharopoulos (HARICA) via 
> Servercert-wg  wrote:
> 
> Hi Ryan,
> 
> The question is not between HTTP vs FTP vs LDAP but specifically for "HTTP 
> URL" that could have two schemes "http" and "https".
> 
> RFC 2616 (June 1999) included only "http" and was updated in May 2000 by RFC 
> 2817  to include TLS Within 
> HTTP/1.1 ("https").
> 
> I hope this clarifies the issue.
> 
> 
> Dimitris.
> 
> On 25/4/2024 3:29 μ.μ., Ryan Dickson via Servercert-wg wrote:
>> It's my understanding that the intent of the updates made in SC-62 were to 
>> prohibit any non-HTTP URI. This was discussed in:
>> 
>> 1) at least one historical GitHub discussion 
>>  (referenced in ballot 
>> preamble 
>> ):
>> 
>> "authorityInformationAccess: This is a new requirement.
>> BRs 7.1.2.2 (c) notes that it SHOULD contain the HTTP URL of the Issuing 
>> CA's certificate and MAY contain the HTTP URL of the Issuing CA's OCSP 
>> responder.
>> Some questions were raised about whether this means other URLs, other 
>> schemes, or multiple URLs can be included. Similar to crlDistributionPoints, 
>> the ordering of URLs implies processing semantics on clients, and only 
>> particular URL schemes are supported. Namely, if one of the two supported 
>> access methods are present (CA issuer or OCSP), then the only URLs present 
>> MUST be HTTP URLs, and MUST be listed in order of priority.
>> This prohibits the use of other access methods, as they are not used in the 
>> Web PKI."
>> 
>> and 2) Corey's Validation Subcommittee presentation at F2F 56 
>> 
>>  (slide 14 
>> ,
>>  "Non-HTTP (i.e., LDAP and FTP) OCSP and CA Issuers URIs are prohibited").
>> 
>> D-Trust volunteered to propose an update to the BRs to address the issue in 
>> this  Bugzilla Bug 
>> (Actions Table).
>> 
>> Thanks,
>> Ryan
>> 
>> On Thu, Apr 25, 2024 at 3:44 AM Adriano Santoni via Servercert-wg 
>> mailto:servercert-wg@cabforum.org>> wrote:
>>> Hi,
>>> 
>>> IMO, including an HTTPS URI in the id-ad-caIssuers accessMethod is at least 
>>> a bad practice and very unwise (if done on purpose), as it may give rise to 
>>> unbounded loops, as it is clearly explained in RFC5280:
>>> 
>>> 
  CAs SHOULD NOT include URIs that specify https, ldaps, or similar
 schemes in extensions.  CAs that include an https URI in one of these
 extensions MUST ensure that the server's certificate can be validated
 without using the information that is pointed to by the URI.  Relying
 parties that choose to validate the server's certificate when
 obtaining information pointed to by an https URI in the
 cRLDistributionPoints, 

Re: Public Discussion of Acquisition of e-commerce monitoring GmbH by AUSTRIA CARD-Plastikkarten und Ausweissysteme GmbH

['Ben Wilson' via dev-security-policy@mozilla.org]

Hi Amir,

Here is a quick update on this issue, while I continue working on a summary
of the discussion concerning the acquisition of e-commerce monitoring by
AUSTRIA CARD.

Since June 1, 2022, section 3.2 of the Mozilla Root Store Policy (MRSP) has
required that ETSI auditors be members of the Accredited Conformity
Assessment Bodies' Council (ACAB'c). One of the underlying reasons for
adopting this requirement was to ensure consistency in auditor
qualifications, guidance, and attestation letters. The ACAB’c membership
requirement continues to help improve the quality of ETSI audits. However,
the MRSP also allows Mozilla to temporarily waive the ACAB’c membership
requirement under certain circumstances.

e-commerce monitoring’s ETSI audit is currently performed by A-SIT (Secure
Information Technology Center – Austria). According to Herbert Leithold,
Executive Director of A-SIT, “A-SIT is a government-funded information
security organisation with formal duties that require strict neutrality and
independency.” For this reason, A-SIT asserts that it is precluded from
joining the ACAB’c. While A-SIT is currently not a member of ACAB'c, it has
otherwise met auditor qualification requirements and its audits have
conformed to templates provided by the ACAB’c.

We are considering whether to grant a temporary approval of A-SIT as an
exception to the ACAB’c membership requirement. Such temporary approval
would be subject to periodic re-evaluation, and likely it would eventually
be withdrawn. We sincerely appreciate everyone's contributions as they
facilitate our ability to make well-informed decisions. We kindly request
your insightful perspectives and opinions.

Thanks,

Ben


On Fri, Apr 26, 2024 at 12:09 PM Amir Omidi (aaomidi) 
wrote:

> Did you ever hear from them?
>
> On Tuesday, March 5, 2024 at 11:18:13 AM UTC-5 Ben Wilson wrote:
>
>> All,
>> March 1 was the scheduled end of public discussion on this matter.
>> However, I have one unresolved question that I have presented to the CA
>> operator and its audit firm regarding ACAB'c membership (see MRSP section
>> 3.2). As soon as I hear back on that question, I'll provide a summary of
>> the entire discussion here.
>> Thanks,
>> Ben
>>
>> On Friday, February 23, 2024 at 7:36:13 AM UTC-7
>> regist...@e-monitoring.at wrote:
>>
>>> *Preface*
>>>
>>> The only thing that changed is the ownership, and the ownership is
>>> represented by the new management. This only formal change has already been
>>> notified to the authorities and approved and registered. The rest remains
>>> unchanged.
>>>
>>> e-commerce monitoring GmbH fulfills different trust service requirements
>>> from ISO/IEC, eIDAS / ETSI, CA/Browser Forum to Root Program requirements,
>>> remains a member of the European Trust List (EUTL) as before and is
>>> permanently monitored by the Austrian Supervisory Body (RTR/TKK) and
>>> regularly assessed by a Conformity Assessment Body.
>>>
>>> The management has changed from Hans G. Zeger to Emmanouil Kontos and
>>> Markus Kirchmayr. The takeover of the company includes the taking over of
>>> the existing, trained and trusted staff which results in no changes except
>>> top management. e-commerce monitoring GmbH continues to provide
>>> certification and trust services according to the respective policies.
>>>
>>> It is in the interest of AUSTRIA CARD-Plastikkarten und Ausweissysteme
>>> Gesellschaft m.b.H. that e-commerce monitoring GmbH continues to fully
>>> comply with the Browser/OS Root Store Policies.
>>>
>>>
>>> *Ownership and Governance*
>>>
>>> The ultimate beneficial owner is Nikolaos Lykos. The new shareholder of
>>> e-commerce monitoring GmbH is AUSTRIA CARD-Plastikkarten und Ausweissysteme
>>> Gesellschaft m.b.H., Nikolaos Lykos owns 77.57 % of shares in AUSTRIACARD
>>> HOLDINGS AG, which is the parent company of AUSTRIA CARD-Plastikkarten und
>>> Ausweissysteme Gesellschaft m.b.H. (it is owned 100% by AUSTRIACARD
>>> HOLDINGS AG).
>>>
>>> AUSTRIACARD HOLDINGS AG is a publically listed company with subsidiaries
>>> in Europe and the USA (please find more details in the prospectus on
>>> AUSTRIACARD´s website (
>>> https://www.austriacard.com/wp-content/uploads/2023/01/AustriaCard_Prospectus_24.01.2023_FINAL.PUBLICATIONpdf.pdf
>>> )
>>>
>>> Emmanouil Kontos is the Managing Director of the company and authorized
>>> to represent the company solely. Markus Kirchmayr is authorized to
>>> represent the company jointly with Emmanouil Kontos. Both will not take any
>>> trusted roles

Re: Find homography in D?

[Jordan Wilson via Digitalmars-d-learn]

On Sunday, 21 April 2024 at 14:57:33 UTC, Paolo Invernizzi wrote:

Hi,

Someone can point me to a D implementation of the classical 
OpenCV find homography matrix?


Thank you,
Paolo


Something I wrote awhile ago...

```
import kaleidic.lubeck : svd;
import gfm.math;
import mir.ndslice : sliced;

auto generateTransformationArray(int[] p) {
return generateTransformationArray(p[0],p[1],p[2],p[3]);
}

auto generateTransformationArray(int x, int y, int x_, int y_) {
return [-x, -y, -1, 0, 0, 0, x*x_, y*x_, x_,
0, 0, 0, -x, -y, -1, x*y_, y*y_, y_];
}

auto transformCoor (mat3d mat, vec3d vec) {
auto res = mat * vec;
return res / res[2];
}

auto findHomography (int[][] correspondances) {
auto a = correspondances
.map!(a => a.generateTransformationArray)
.joiner
.array
.sliced(8,9);

auto r = a.svd;
auto homog = r.vt.back;
return mat3d(homog.map!(a => a/homog.back).array);
}
```

[Wikitech-ambassadors] Tech News 2024, week 18

[Nick Wilson (Quiddity)]

The latest technical newsletter is now available at
https://meta.wikimedia.org/wiki/Special:MyLanguage/Tech/News/2024/18 -
Below is the English version.
You can help write the next newsletter: Whenever you see information about
Wikimedia technology that you think should be distributed more broadly, you
can add it to the next newsletter at
https://meta.wikimedia.org/wiki/Tech/News/Next .
More information on how to contribute is available. You can also contact me
directly.
As always, feedback (on- or off-list) is appreciated and encouraged.
——
Other languages: Deutsch
, English, Ghanaian
Pidgin , Tiếng Việt
, español
, français
, italiano
, norsk bokmål
, polski
, português
, português do Brasil
, svenska
, čeština
, русский
, українська
, עברית
, العربية
, فارسی
, বাংলা
, 中文


Latest *tech news
* from the
Wikimedia technical community. Please tell other users about these changes.
Not all changes will affect you. Translations
 are
available.

*Recent changes*

   - The appearance of talk pages changed for the following wikis:
   Azerbaijani Wikipedia, Bengali Wikipedia, German Wikipedia, Persian
   Wikipedia, Hebrew Wikipedia, Hindi Wikipedia, Indonesian Wikipedia, Korean
   Wikipedia, Dutch Wikipedia, Portuguese Wikipedia, Romanian Wikipedia, Thai
   Wikipedia, Turkish Wikipedia, Ukrainian Wikipedia, Vietnamese Wikipedia.
   These wikis participated to a test, where 50% of users got the new design,
   for one year. As this test gave positive results
   
,
   the new design is deployed on these wikis as the default design. It is
   possible to opt-out these changes in user preferences
   
   ("Show discussion activity"). The deployment will happen at all wikis in
   the coming weeks. [1] 
   - Seven new wikis have been created:
  - a Wikipedia in Betawi  (w:bew:
  ) [2]
  
  - a Wikipedia in Kusaal  (w:kus:
  ) [3]
  
  - a Wikipedia in Igala  (w:igl:
  ) [4]
  
  - a Wiktionary in Karakalpak  (
  wikt:kaa: ) [5]
  
  - a Wikisource in Burmese  (s:my:
  ) [6]
  
  - a Wikisource in Malay  (s:ms:
  ) [7]
  
  - a Wikisource in Georgian  (
  s:ka: ) [8]
  
   - You can now watch message groups/projects
   

   on Translatewiki.net
   .
   Initially, this feature will notify you of added or deleted messages in
   these groups. [9] 
   - Dark mode is now available on all wikis, on mobile web for logged-in
   users who opt into the advanced mode
   . This is the
   early release of the feature. Technical editors are 

[Translators-l] Re: Tech News #18, 2024

[Nick Wilson (Quiddity)]

Thank you all for your help! It is deeply appreciated. The newsletter has
now been delivered (in 20 languages) to 1,112 pages.
___
Translators-l mailing list -- translators-l@lists.wikimedia.org
To unsubscribe send an email to translators-l-le...@lists.wikimedia.org

[African Wikimedians] [Wiki Loves Africa] Dernier appel pour les téléchargements du concours 2024

[Wilson Oluoha]

Chers amis,

Je suis heureux de vous annoncer que Wiki Loves Africa 2024
<https://commons.wikimedia.org/wiki/Commons:Wiki_Loves_Africa_2024> - L'Afrique
crée
<https://commons.wikimedia.org/wiki/Commons:Wiki_Loves_Africa_2024/Theme>,
a été un grand succès jusqu'à présent et de vous assurer que nous avons
reçu toutes vos belles soumissions
<https://commons.wikimedia.org/wiki/Category:Images_from_Wiki_Loves_Africa_2024>
- photos, audio, vidéo, etc.

Merci beaucoup! ❤️

Cet e-mail a pour but de vous rappeler que *le concours se termine
officiellement le 30 avril* (demain minuit AOE). N'oubliez pas de mettre la
touche finale et de télécharger les photos qu'il vous reste. Vous pouvez
également envisager de créer des essais photographiques avec vos
contributions ici
<https://commons.wikimedia.org/wiki/Commons:Wiki_Loves_Africa_2024/photo_essay/Enter_photo_essay_2024>
.

N'hésitez pas à contacter votre organisateur communautaire local ou
moi-même si vous avez des questions ou des problèmes à résoudre.

Cliquez ici pour soumettre votre candidature à Wiki Loves Africa 2024
<https://commons.wikimedia.org/w/index.php?title=Special:UploadWizard=wlafrica>
(n'oubliez pas de sélectionner votre pays).

Je vous remercie tous encore une fois pour les contributions reçues jusqu'à
présent.

Cordialement,

-- 

*Wilson Oluoha*

UTC+1

Skype: studywilson1106 | Telegram: @Wilsn_Oluoha | Whatsapp: message
<https://wa.me/2348069451106>

Wikimedia  <https://meta.wikimedia.org/wiki/User:OtuNwachinemere>|
<https://www.linkedin.com/in/devouard/>LinkedIn
<https://www.linkedin.com/in/wilson-oluoha-a2b4a6181/> | Website
<https://www.wikilovesafrica.net/> | Instagram
<https://instagram.com/i_see_a_picture> | Twitter
<https://twitter.com/OluohaWilson>

Hear my name <https://namedrop.io/wilsonoluoha>
___
African-Wikimedians mailing list -- african-wikimedians@lists.wikimedia.org
To unsubscribe send an email to african-wikimedians-le...@lists.wikimedia.org

[African Wikimedians] [Wiki Loves Africa] Final call for 2024 Contest Uploads

[Wilson Oluoha]

Dear Friends,

I am excited to let you know that Wiki Loves Africa 2024
<https://commons.wikimedia.org/wiki/Commons:Wiki_Loves_Africa_2024> - *Africa
creates
<https://commons.wikimedia.org/wiki/Commons:Wiki_Loves_Africa_2024/Theme>*,
has been a great success so far and to assure you that we have received all
your beautiful submissions
<https://commons.wikimedia.org/wiki/Category:Images_from_Wiki_Loves_Africa_2024>
- photos, audio, video etc.

Thank you! ❤️

This email is to remind you that the *contest ends officially on the 30th
April* (*tomorrow midnight AOE*). Please be sure to put your final touches
and upload whatever submissions you have left. You can also consider
creating photo Essays with your submissions here
<https://commons.wikimedia.org/wiki/Commons:Wiki_Loves_Africa_2024/photo_essay/Enter_photo_essay_2024>
.

Kindly reach out to your local community organizer and or *myself *if you
have any questions or challenges you need resolved.

Click here to make a submission to Wiki Loves Africa 2024
<https://commons.wikimedia.org/w/index.php?title=Special:UploadWizard=wlafrica>
(don't forget to select your country).

Thank you all once again for the submissions so far.

Best,


-- 

*Wilson Oluoha*

UTC+1

Skype: studywilson1106 | Telegram: @Wilsn_Oluoha | Whatsapp: message
<https://wa.me/2348069451106>

Wikimedia  <https://meta.wikimedia.org/wiki/User:OtuNwachinemere>|
<https://www.linkedin.com/in/devouard/>LinkedIn
<https://www.linkedin.com/in/wilson-oluoha-a2b4a6181/> | Website
<https://www.wikilovesafrica.net/> | Instagram
<https://instagram.com/i_see_a_picture> | Twitter
<https://twitter.com/OluohaWilson>

Hear my name <https://namedrop.io/wilsonoluoha>
___
African-Wikimedians mailing list -- african-wikimedians@lists.wikimedia.org
To unsubscribe send an email to african-wikimedians-le...@lists.wikimedia.org

Re: GESO: Spiders and Snake

[mike wilson]

Spiders don't have antennae, which yours clearly does. Also, I can't make out 
more than six legs.  Some ant species are hairy and the queens chew off their 
wings after fertilisation.  I wonder if the same happens with some species of 
bumble bees?  There is a scarlet tailed bumblebee, Bombus coccineus but I don't 
have any other information about it.
> On 29/04/2024 08:24 BST Larry Colen  wrote:
> 
>  
> I looked up "Red fuzzy butt spider" and was pointed to the Johnson Jumper:
> https://www.inaturalist.org/guide_taxa/682651
> 
> Mind you, my inner 12 year old goes a very different place with the phrase 
> "Johnson Jumper".
> 
> Oh, and I think the snake might be a red diamond rattlesnake.
> 
> 
> > On Apr 29, 2024, at 12:14 AM, mike wilson  wrote:
> > 
> > Not spiders.  Some form of wingless bee?
> >> On 29/04/2024 08:05 BST Larry Colen  wrote:
> >> 
> >> 
> >> Mediocre photos of cute spiders with fuzzy red butts, and better photos of 
> >> a rattlesnake.  I've never seen one like this before, very different 
> >> colors and markings than I'm used to.
> >> 
> >> 
> >> Yeah, the album starts out with some flowers because some people are funny 
> >> about the weirdest things.
> >> 
> >> https://www.flickr.com/photos/ellarsee/albums/72177720316568151/
--
%(real_name)s Pentax-Discuss Mail List
To unsubscribe send an email to pdml-le...@pdml.net
to UNSUBSCRIBE from the PDML, please visit the link directly above and follow 
the directions.

Re: GESO: Spiders and Snake

[mike wilson]

Not spiders.  Some form of wingless bee?
> On 29/04/2024 08:05 BST Larry Colen  wrote:
> 
>  
> Mediocre photos of cute spiders with fuzzy red butts, and better photos of a 
> rattlesnake.  I've never seen one like this before, very different colors and 
> markings than I'm used to.
> 
> 
> Yeah, the album starts out with some flowers because some people are funny 
> about the weirdest things.
> 
> https://www.flickr.com/photos/ellarsee/albums/72177720316568151/
>
--
%(real_name)s Pentax-Discuss Mail List
To unsubscribe send an email to pdml-le...@pdml.net
to UNSUBSCRIBE from the PDML, please visit the link directly above and follow 
the directions.

RE: [neonixie-l] ZM1350

[Michail Wilson]

Sorry bud, if I knew it was you…… Ummm, Ok, I would still have bid on them.  
Heh.
Finally, after many years of waiting on them, they appeared on ebay (at least 
that I have noticed) and barely got them because of the UK only listing.

I’m excited to make ‘something’ with them.

Michail Wilson
206-920-6312

From: neonixie-l@googlegroups.com  On Behalf Of 
Richard Scales
Sent: Sunday, April 28, 2024 11:01 PM
To: neonixie-l 
Subject: Re: [neonixie-l] ZM1350

I bid too (I am in the UK and I was aware of their provenance and I live just 
20 minutes away from them!) - it was interesting watching the numbers going up!

I'd be fairly confident that they were all good.

Well done on outbidding me ;-)

- Richard


On Monday 29 April 2024 at 03:18:24 UTC+1 Michail Wilson wrote:
I won the auction which some might wonder how since they were not sold to the 
USA.
I’ve been talking to a guy from the Ukraine and he sent me a link.  I decided I 
wanted them, but seller would not ship out of the country.

I’m in a Bitcoin forum/chat rooms and someone I’ve dealt with for a while had 
me thinking….. I had him bid and pay for me.

Story on the auction… Not tested.  Auction says 6, but 4 extra included just in 
case.   So, possibly 10.   Since I’ve only ever had two, I decided to win it.
Talking to seller and it turns out they were part of the late John Smout’s 
collection.  Now I got really excited and thinking all 10 should be good.

Two days prior to having a friend bid on them had me worried, because he didn’t 
answer messages.  Uhhhg.  He came through and manually bid for me.

So, a double shipping, and I will find out in about a month.  Well, maybe 
longer since I don’t have any project boards, etc.

My guess is about 1125 L total.  Around $150 each assuming all are good.  Not 
considering the extras in the package yet.

Note:  I picked up another of his auctions as well which was VFDs.  IV-25’s

Michail Wilson
206-920-6312

From: neoni...@googlegroups.com  On Behalf Of 
Nicholas Stock
Sent: Sunday, April 28, 2024 4:31 PM
To: neoni...@googlegroups.com
Subject: Re: [neonixie-l] ZM1350

I've given up thinking what a good price is now that looks like about $200 
each when taking tax/currency conversion into account.

They are very nice tubes when lit up. They've gone to a good home (presumably 
Michail from his smiley face reply... ;)

On Sun, Apr 28, 2024 at 4:28 PM Robert  wrote:
Good price?


Rob

On 28 Apr 2024, at 16:16, Michail Wilson  wrote:



Michail Wilson
206-920-6312

From: neoni...@googlegroups.com  On Behalf Of Robert
Sent: Sunday, April 28, 2024 4:55 AM
To: neoni...@googlegroups.com
Subject: [neonixie-l] ZM1350

Not my auction but did anyone on here get them

 
https://www.ebay.co.uk/itm/266778846760?mkcid=16=1=711-127632-2357-0=oUHk6HLEQUG=4429486=U1YeAcPgQ5y=_ver=artemis=COPY<https://www.ebay.co.uk/itm/266778846760?mkcid=16=1=711-127632-2357-0=oUHk6HLEQUG=4429486=U1YeAcPgQ5y=_ver=artemis=COPY>


Rob
--
You received this message because you are subscribed to the Google Groups 
"neonixie-l" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to neonixie-l+...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/neonixie-l/E7BC25D2-B3E4-4C9B-8D2D-B0B8BC7C5C10%40gmail.com<https://groups.google.com/d/msgid/neonixie-l/E7BC25D2-B3E4-4C9B-8D2D-B0B8BC7C5C10%40gmail.com?utm_medium=email_source=footer>.
--
You received this message because you are subscribed to the Google Groups 
"neonixie-l" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to neonixie-l+...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/neonixie-l/SA0PR01MB617010535213044DDD4849CA82142%40SA0PR01MB6170.prod.exchangelabs.com<https://groups.google.com/d/msgid/neonixie-l/SA0PR01MB617010535213044DDD4849CA82142%40SA0PR01MB6170.prod.exchangelabs.com?utm_medium=email_source=footer>.
--
You received this message because you are subscribed to the Google Groups 
"neonixie-l" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to neonixie-l+...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/neonixie-l/9455D4FD-B81B-4131-A101-CB70B3EA8068%40gmail.com<https://groups.google.com/d/msgid/neonixie-l/9455D4FD-B81B-4131-A101-CB70B3EA8068%40gmail.com?utm_medium=email_source=footer>.
--
You received this message because you are subscribed to the Google Groups 
"neonixie-l" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to neonixie-l+...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/neonixie-l/CAOX%2BRH%2Bq1%2B%3Du%3D0Yj6vBX3O-BPsVgP4Tkqdvj0smn_S6VJtFoLw%40mail.gmail.com<https://groups.google.com/d/msgid/neonixie-l/CAOX%2BRH%2Bq1%2B%3Du%3D0Yj6vBX3O-BPsVgP4Tkqdvj0smn

RE: [neonixie-l] ZM1350

[Michail Wilson]

I won the auction which some might wonder how since they were not sold to the 
USA.
I’ve been talking to a guy from the Ukraine and he sent me a link.  I decided I 
wanted them, but seller would not ship out of the country.

I’m in a Bitcoin forum/chat rooms and someone I’ve dealt with for a while had 
me thinking….. I had him bid and pay for me.

Story on the auction… Not tested.  Auction says 6, but 4 extra included just in 
case.   So, possibly 10.   Since I’ve only ever had two, I decided to win it.
Talking to seller and it turns out they were part of the late John Smout’s 
collection.  Now I got really excited and thinking all 10 should be good.

Two days prior to having a friend bid on them had me worried, because he didn’t 
answer messages.  Uhhhg.  He came through and manually bid for me.

So, a double shipping, and I will find out in about a month.  Well, maybe 
longer since I don’t have any project boards, etc.

My guess is about 1125 L total.  Around $150 each assuming all are good.  Not 
considering the extras in the package yet.

Note:  I picked up another of his auctions as well which was VFDs.  IV-25’s

Michail Wilson
206-920-6312

From: neonixie-l@googlegroups.com  On Behalf Of 
Nicholas Stock
Sent: Sunday, April 28, 2024 4:31 PM
To: neonixie-l@googlegroups.com
Subject: Re: [neonixie-l] ZM1350

I've given up thinking what a good price is now that looks like about $200 
each when taking tax/currency conversion into account.

They are very nice tubes when lit up. They've gone to a good home (presumably 
Michail from his smiley face reply... ;)

On Sun, Apr 28, 2024 at 4:28 PM Robert 
mailto:robnorman...@gmail.com>> wrote:
Good price?


Rob


On 28 Apr 2024, at 16:16, Michail Wilson 
mailto:m...@michail.com>> wrote:



Michail Wilson
206-920-6312

From: neonixie-l@googlegroups.com<mailto:neonixie-l@googlegroups.com> 
mailto:neonixie-l@googlegroups.com>> On Behalf Of 
Robert
Sent: Sunday, April 28, 2024 4:55 AM
To: neonixie-l@googlegroups.com<mailto:neonixie-l@googlegroups.com>
Subject: [neonixie-l] ZM1350

Not my auction but did anyone on here get them

 
https://www.ebay.co.uk/itm/266778846760?mkcid=16=1=711-127632-2357-0=oUHk6HLEQUG=4429486=U1YeAcPgQ5y=_ver=artemis=COPY<https://www.ebay.co.uk/itm/266778846760?mkcid=16=1=711-127632-2357-0=oUHk6HLEQUG=4429486=U1YeAcPgQ5y=_ver=artemis=COPY>


Rob
--
You received this message because you are subscribed to the Google Groups 
"neonixie-l" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
neonixie-l+unsubscr...@googlegroups.com<mailto:neonixie-l+unsubscr...@googlegroups.com>.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/neonixie-l/E7BC25D2-B3E4-4C9B-8D2D-B0B8BC7C5C10%40gmail.com<https://groups.google.com/d/msgid/neonixie-l/E7BC25D2-B3E4-4C9B-8D2D-B0B8BC7C5C10%40gmail.com?utm_medium=email_source=footer>.
--
You received this message because you are subscribed to the Google Groups 
"neonixie-l" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
neonixie-l+unsubscr...@googlegroups.com<mailto:neonixie-l+unsubscr...@googlegroups.com>.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/neonixie-l/SA0PR01MB617010535213044DDD4849CA82142%40SA0PR01MB6170.prod.exchangelabs.com<https://groups.google.com/d/msgid/neonixie-l/SA0PR01MB617010535213044DDD4849CA82142%40SA0PR01MB6170.prod.exchangelabs.com?utm_medium=email_source=footer>.
--
You received this message because you are subscribed to the Google Groups 
"neonixie-l" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
neonixie-l+unsubscr...@googlegroups.com<mailto:neonixie-l+unsubscr...@googlegroups.com>.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/neonixie-l/9455D4FD-B81B-4131-A101-CB70B3EA8068%40gmail.com<https://groups.google.com/d/msgid/neonixie-l/9455D4FD-B81B-4131-A101-CB70B3EA8068%40gmail.com?utm_medium=email_source=footer>.
--
You received this message because you are subscribed to the Google Groups 
"neonixie-l" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
neonixie-l+unsubscr...@googlegroups.com<mailto:neonixie-l+unsubscr...@googlegroups.com>.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/neonixie-l/CAOX%2BRH%2Bq1%2B%3Du%3D0Yj6vBX3O-BPsVgP4Tkqdvj0smn_S6VJtFoLw%40mail.gmail.com<https://groups.google.com/d/msgid/neonixie-l/CAOX%2BRH%2Bq1%2B%3Du%3D0Yj6vBX3O-BPsVgP4Tkqdvj0smn_S6VJtFoLw%40mail.gmail.com?utm_medium=email_source=footer>.

-- 
You received this message because you are subscribed to the Google Groups 
"neonixie-l" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to neonixie-l+unsubscr...@googlegroups.com.
To view 

RE: [neonixie-l] ZM1350

[Michail Wilson]



Michail Wilson
206-920-6312

From: neonixie-l@googlegroups.com  On Behalf Of 
Robert
Sent: Sunday, April 28, 2024 4:55 AM
To: neonixie-l@googlegroups.com
Subject: [neonixie-l] ZM1350

Not my auction but did anyone on here get them

 
https://www.ebay.co.uk/itm/266778846760?mkcid=16=1=711-127632-2357-0=oUHk6HLEQUG=4429486=U1YeAcPgQ5y=_ver=artemis=COPY<https://www.ebay.co.uk/itm/266778846760?mkcid=16=1=711-127632-2357-0=oUHk6HLEQUG=4429486=U1YeAcPgQ5y=_ver=artemis=COPY>


Rob
--
You received this message because you are subscribed to the Google Groups 
"neonixie-l" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
neonixie-l+unsubscr...@googlegroups.com<mailto:neonixie-l+unsubscr...@googlegroups.com>.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/neonixie-l/E7BC25D2-B3E4-4C9B-8D2D-B0B8BC7C5C10%40gmail.com<https://groups.google.com/d/msgid/neonixie-l/E7BC25D2-B3E4-4C9B-8D2D-B0B8BC7C5C10%40gmail.com?utm_medium=email_source=footer>.

-- 
You received this message because you are subscribed to the Google Groups 
"neonixie-l" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to neonixie-l+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/neonixie-l/SA0PR01MB617010535213044DDD4849CA82142%40SA0PR01MB6170.prod.exchangelabs.com.

[Translators-l] Re: Tech News #18, 2024

[Nick Wilson (Quiddity)]

On Thu, Apr 25, 2024 at 4:57 PM Nick Wilson (Quiddity) <
nwil...@wikimedia.org> wrote:

> The latest tech newsletter is ready for early translation:
> https://meta.wikimedia.org/wiki/Tech/News/2024/18
>
> Direct translation link:
>
> https://meta.wikimedia.org/w/index.php?title=Special:Translate=page-Tech%2FNews%2F2024%2F18=page
>

The text of the newsletter is now final.

*One entry was added, and one entry was changed*, since yesterday.

There won't be any more changes; you can translate safely. Thanks!
___
Translators-l mailing list -- translators-l@lists.wikimedia.org
To unsubscribe send an email to translators-l-le...@lists.wikimedia.org

Re: [cabf_netsec] Voting Period Begins | Ballot NS-003: Restructure the NCSSRs

[Clint Wilson via Netsec]

Apple votes YES on Ballot NS-003.

> On Apr 23, 2024, at 8:59 AM, Clint Wilson via Netsec  
> wrote:
> 
> Ballot NS-003 is proposed by Clint Wilson of Apple and endorsed by Trevoli 
> Ponds-White of Amazon and David Kluge of Google Trust Services.
> 
> Purpose of Ballot
> 
> This ballot proposes a comprehensive restructuring of the Network and 
> Certificate System Security Requirements (NCSSRs), excepting Section 4. The 
> current structure of the document has proven to be challenging for creating 
> ballots, contains duplicated requirements, and separates similar requirements 
> across the document. These issues have led to inefficiencies in managing and 
> implementing security standards. Therefore, this proposal aims to streamline 
> the document's structure, eliminate redundancies, improve comprehensibility, 
> and enhance clarity and coherence.
> 
> Reasons for Proposal:
> 
> Complexity in Ballot Creation: The current document structure can make it 
> difficult to create and manage ballots efficiently, leading to somewhat 
> awkward updating processes, abandoned ballots, and a lack of confidence that 
> ballots effect the intended changes.
> Redundancy: Over time, some parts of the NCSSRs have touched on the same 
> topic, leading to some duplication across the document and further to 
> confusion and inconsistency in implementation.
> Fragmentation: Similar requirements for different parts of a CA’s 
> NCSSR-relevant infrastructure are scattered throughout the document, making 
> it somewhat more difficult for to locate and comprehend a complete picture of 
> these requirements effectively.
> Minor Issues: The document contains other, more minor issues that also impede 
> its usability and effectiveness, such as missing definitions, unclear list 
> structures, and requirements that are more optional than they may currently 
> appear.
> 
> Benefits of the Updated Document Structure:
> 
> Enhanced Clarity: The revised structure should improve the clarity and 
> coherence of the document, making the requirements it represents easier to 
> understand, as well as result in greater consistency when implementing or 
> assessing its security requirements.
> Future Updates: A more granular document structure should improve the process 
> of creating and managing ballots in the future. Similarly, the improved 
> proximity of related requirements should hopefully aid in identifying the 
> areas the NCSSRs can most benefit from further attention.
> Grouping and De-duplication of Similar Requirements: By consolidating 
> duplicated requirements, the updated document should make it much easier to 
> find, comprehend, assess, and implement related requirements.
> Clearer Recommendations: The updated document includes a number of additional 
> “SHOULD”-type stipulations, clarifying some of the language in the current 
> NCSSRs such that it’s easier to identify where the NCSSRs impose a strict 
> requirement as opposed to a strong recommendation.
> 
> Overall, this ballot proposal seeks to address existing challenges in 
> updating the current version of the NCSSRs and pave the way for future 
> improvements to the NCSSRs.
> 
> MOTION BEGINS
> 
> This ballot modifies the “Network and Certificate System Security 
> Requirements” as follows, based on version 1.7:
> 
> https://github.com/cabforum/netsec/compare/c62a2f88e252de5c79b101fa3c9e9c536388639a...8bd66d27c07e30d1f4d9e6dd57b075bca499bf2e
> 
> MOTION ENDS
> 
> The procedure for approval of this ballot is as follows:
> 
> Discussion Period (14+ days)
> 
> Start Time: 2024-April-09 16:00 UTC
> End Time: 2024-April-23 15:59 UTC
> 
> Voting Period (7 days)
> 
> Start Time: 2024-April-23 16:00 UTC
> End Time: 2024-April-30 16:00 UTC
> ___
> Netsec mailing list
> Netsec@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/netsec



smime.p7s
Description: S/MIME cryptographic signature
___
Netsec mailing list
Netsec@cabforum.org
https://lists.cabforum.org/mailman/listinfo/netsec

Re: [PSES] DoC - reference to ROHS directive

[Matthew Wilson | GBE]

In our experience purchasers/compliance officers in large retail organisations 
expect to explicitly see the RoHS amendment listed in the DoC text as per Mike 
writes below, because this ticks their box that the product has addressed the 
additional four substances the amendment was concerned with.  They may also 
want it to say ‘RoHS 3’ in the DoC and supporting documentation (technical 
file) too.

Hence a triumph of commercial requirements/persons with clipboards(!) to use 
colloquial terms and extra words over the actual obligation.  I gave up arguing 
and just did what they wanted, path of least resistance and all that!

Have had some other run ins with some retailers on some other things too that 
weren’t relevant to the product in question, but they wanted it declared none 
the less.  I won that one though   A story for my book for whenever I get to 
retirement age (probably never because the UK will be broke by then but I 
digress!)

Matthew Wilson,
GB Electronics (UK) Ltd.


Matthew WilsonMIET
Technical Director
GB Electronics (UK) Ltd
matthew.wil...@gbelectronics.com
www.gbelectronics.com
+44 (0) 1903 244 500
Ascot House|Mulberry Close|Woods Way
Goring-by-Sea|West Sussex|BN12 4QY|UK
Certificate Number 10455
​ISO 9001, ISO 14001
Disclaimer: This email and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.
​If you have received this email in error please delete it from your system, do 
not use or disclose the information in any way and notify the sender 
immediately.
​The contents of this message may contain personal views which are not the 
views of the company, unless specifically stated.
​
​GB Electronics (UK) Ltd is a company registered in England and Wales under 
number 06210991.
​Registered office: Ascot House Mulberry Close, Woods Way, Goring By Sea, West 
Sussex, BN12 4QY.
From: Charlie Blackham 
Sent: Monday, April 22, 2024 7:26 AM
To: EMC-PSTC@LISTSERV.IEEE.ORG
Subject: Re: [PSES] DoC - reference to ROHS directive

I wouldn’t say that it was “wrong” to add the amendment, though I don’t 
recommend adding it, but since the amendment applies whether you like it or 
not, you don’t need to declare that you have applied it as it’s inherent in a 
declaration to 2011/65/EU.

The same goes for any exemptions you may have applied, or indeed have 
previously applied but have now expired.

Best regards
Charlie

Charlie Blackham
Sulis Consultants Ltd
Tel: +44 (0)7946 624317
Web: https://sulisconsultants.com/
Registered in England and Wales, number 05466247

From: MIKE SHERMAN mailto:msherma...@comcast.net>>
Sent: Monday, April 22, 2024 2:43 AM
To: EMC-PSTC@LISTSERV.IEEE.ORG<mailto:EMC-PSTC@LISTSERV.IEEE.ORG>
Subject: Re: [PSES] DoC - reference to ROHS directive

What I've seen is language like
"2011/65/EU RoHS directive with amendment 2015/863/EU"
or
"2011/65/EU RoHS directive as amended by 2015/863/EU"

The 2015 amendment adds four substances to the original six, so you should 
mention both it and the 2011 directive.

Mike Sherman
Sherman PSC LLC
On 04/21/2024 12:52 PM CDT Amund Westin 
mailto:am...@westin-emission.no>> wrote:


I have the last 10+ years made reference to ROHS directive 2011/65/EU in the 
DoC.
Now, I have been told to switch to 2015/863/EU? Is that correct?

>From what I see on the EU web site, 2015/863 is a Commission Delegated 
>Directive, amending Annex II to Directive 2011/65/EU
As I understand, 2011/65/EU is still in charge, and is the directive to be 
listed in the DoC.

Comments?

BR Amund




This message is from the IEEE Product Safety Engineering Society emc-pstc 
discussion list. To post a message to the list, send your e-mail to 
EMC-PSTC@LISTSERV.IEEE.ORG<mailto:EMC-PSTC@LISTSERV.IEEE.ORG>
All emc-pstc postings are archived and searchable on the web at:
https://www.mail-archive.com/emc-pstc@listserv.ieee.org/



Website: https://ewh.ieee.org/soc/pses/
Instructions: https://ewh.ieee.org/soc/pses/list.html (including how to 
unsubscribe)<https://ewh.ieee.org/soc/pses/list.html>
List rules: https://ewh.ieee.org/soc/pses/listrules.html

For help, send mail to the list administrators:
Mike Sherman at: msherma...@comcast.net<mailto:msherma...@comcast.net>
Rick Linford at: linf...@ieee.org<mailto:linf...@ieee.org>

For policy questions, send mail to:
Jim Bacher at: j.bac...@ieee.org<mailto:j.bac...@ieee.org>



To unsubscribe from the EMC-PSTC list, click the following link: 
https://listserv.ieee.org/cgi-bin/wa?SUBED1=EMC-PSTC=1



This message is from the IEEE Product Safety Engineering Society emc-pstc 
discussion list. To post a message to the list, send your e-mail to 
EMC-PSTC@LISTSERV.IEEE.ORG<mailto:EMC-PSTC@LISTSERV.IEEE.ORG>
All emc-pstc postings are archived and searchable on the web at:
https://www.ma

Re: [Servercert-wg] Voting Period Begins - Ballot SC-073: Compromised and Weak Keys

[Ben Wilson via Servercert-wg]

Mozilla votes "yes".

On Fri, Apr 26, 2024 at 2:00 AM Wayne Thayer via Servercert-wg <
servercert-wg@cabforum.org> wrote:

> Purpose of Ballot SC-073
>
> This ballot proposes updates to the Baseline Requirements for the Issuance
> and Management of Publicly-Trusted TLS Server Certificates related to weak
> and compromised private keys. These changes lie primarily in Section
> 6.1.1.3:
>
>-
>
>6.1.1.3(4) clarifies that, for the purpose of this requirement, CAs
>shall be made aware of compromised keys using their existing notification
>mechanism(s).
>-
>
>6.1.1.3(5) improves guidance for CAs around the detection of weak
>keys. Should this ballot pass, these changes become effective on November
>15, 2024.
>
> Notes:
>
>-
>
>This ballot builds on the extensive work done by SSL.com in creating
>ballot SC-59v2 Weak Key Guidance. SSL.com’s contributions are appreciated.
>-
>
>Thanks to Rob Stradling of Sectigo for the generation and publication
>of the set of Debian weak keys referenced in this ballot.
>-
>
>The Debian weak keys requirements have been discussed extensively,
>including in the following threads:
>https://lists.cabforum.org/pipermail/servercert-wg/2024-March/004291.html
>and
>https://lists.cabforum.org/pipermail/servercert-wg/2024-April/004422.html
>
>-
>
>This ballot does not appear to conflict with any other ballots that
>are currently under discussion.
>
>
> The following motion has been proposed by Wayne Thayer of Fastly, and
> endorsed by Brittany Randall of GoDaddy and Bruce Morton of Entrust.
>
> — Motion Begins —
>
> This ballot modifies the “Baseline Requirements for the Issuance and
> Management of Publicly-Trusted Certificates” (“Baseline Requirements”),
> based on Version 2.0.3.
>
> MODIFY the Baseline Requirements for the Issuance and Management of
> Publicly-Trusted TLS Server Certificates as specified in the following
> Redline:
>
> Here is a link to the immutable GitHub redline:
> https://github.com/cabforum/servercert/compare/a65402cff89affe1fc0a1f0e49807c7e42e1608a...bee10c8e4a56815bffd59fab12cbd4044baa7cc0
>
>
> — Motion Ends —
>
> This ballot proposes a Final Maintenance Guideline. The procedure for
> approval of this ballot is as follows:
>
> Discussion (7+ days)
>
>-
>
>Start time: 2024-04-18 00:00:00 UTC
>-
>
>End time: 2024-04-26 00:00:00 UTC
>
> Vote for approval (7 days)
>
>-
>
>Start time: 2024-04-26 00:00:00 UTC
>- End time: 2024-05-03 00:00:00 UTC
>
> ___
> Servercert-wg mailing list
> Servercert-wg@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

[Translators-l] Tech News #18, 2024

[Nick Wilson (Quiddity)]

The latest tech newsletter is ready for early translation:
https://meta.wikimedia.org/wiki/Tech/News/2024/18

Direct translation link:
https://meta.wikimedia.org/w/index.php?title=Special:Translate=page-Tech%2FNews%2F2024%2F18=page

We plan to send the newsletter on Monday afternoon (UTC), i.e. Monday
morning PT. The existing translations will be posted on the wikis in
that language. Deadlines:
https://meta.wikimedia.org/wiki/Tech/News/For_contributors#The_deadlines

There will be more edits by Friday midnight UTC but the existing content
should
generally remain fairly stable. I will let you know on Friday in any
case.

Let us know if you have any questions, comments or concerns. As
always, we appreciate your help and feedback.

(If you haven't translated Tech News previously, see this email:
https://lists.wikimedia.org/pipermail/translators-l/2017-January/003773.html

Thank you!
___
Translators-l mailing list -- translators-l@lists.wikimedia.org
To unsubscribe send an email to translators-l-le...@lists.wikimedia.org

Re: [go-cd] Elastic agents plugin usage

[Chad Wilson]

It seems you are using the third party EC2 Elastic Agent Plugin
. This plugin
does not implement the plugin API correctly
 and
does not support environments correctly, which is presumably why you have
that user data hack.

It seems to me from a quick look at the code, this plugin only runs a
single job on an EC2 instance before terminating it so you shouldn't expect
re-use for multiple jobs. If you want to know more about how it is
designed, you are better to ask on their GitHub repo.

I don't know 100% why your agents aren't shutting down correctly, and you
probably need to look at the plugin logs (on both server and the agent
itself) to investigate.

However, since it looks like you have a ec2_user_data hack in place to get
some environment support with the plugin, you need to manually make sure
that the environments in the config agent.auto.register.
environments=staging,sandbox *exactly match the possible pipeline
environments for all possible jobs* you assign to this elastic agent
profile ID.

I also think having multiple environments registered here will possibly
cause chaos, because that is not how elastic agents manage environments
normally. They normally register only a single environment.

The problem will be that if *any single job* on your GoCD is assigned to
say, profile "*elastic_profile_staging*" with the autoregister config like
you have below, but then that job is configured for a pipeline inside a
GoCD environment called* "**other_env**" *an elastic agent will start but
then never get assigned the job. This is because it has registered only for
"*staging,sandbox*" via your hardcoded user_data, NOT "*other_env*".

This breaks the elastic agent plugin contract - GoCD thinks it has already
told the plugin to create an agent for "*other_env*", but it never does.
Now GoCD is confused as to what is happening with the agents. Thus the job
will likely never get assigned, and the plugin will never complete a job,
and it will never shut down the EC2 instance. Perhaps this is what is
happening to you? Might want to check if you have EC2 instances whose agent
logs don't show them doing any work or mismatched environments and elastic
profiles.

With a correctly behaving plugin GoCD tells the plugin a single environment
to register for (the one it needs a new agent to run a job on), and expects
the plugin to register for the environment it tells it to. This EC2 plugin
breaks that contract, which allows you to misconfigure things very easily
and create all sorts of problems. Personally I wouldn't use it if I am
using GoCD environments, but that's your decision to make.

-Chad

On Thu, Apr 25, 2024 at 10:48 PM Satya Elipe  wrote:

> Thank you Sriram.
> Please find my comments below.
>
> >Do the various jobs have an elastic profile ID set?
> Yes, I have two environments staging and prod, so we have separate
> profiles set for them.
>
> Here is pretty much what each profile has:
>
>1. ec2_ami
>2. ec2_instance_profile
>3. ec2_subnets
>4. ec2_instance_type
>5. ec2_key
>6. ec2_user_data
>*echo "agent.auto.register.environments=staging,sandbox" | sudo tee -a
>/var/lib/go-agent/config/autoregister.properties > /dev/null*
>7. ec2_sg
>
>
> >What is the error that you see due to the max count limit?
> ```
> [go] Received request to create an instance for
> brxt-config-service-deploy-production/19/prepare-deploy-stage/1/prepare-deploy-job
> at 2024-04-09 11:21:38 +00:00
> [go] Successfully created new instance i-093b44f70992505cc in
> subnet-555bba0d
> [go] Received request to create an instance for
> brxt-config-service-deploy-production/19/prepare-deploy-stage/1/prepare-deploy-job
> at 2024-04-09 11:23:38 +00:00
> [go] The number of instances currently running is currently at the maximum
> permissible limit, "2". Not creating more instances for jobs:
> brxt-core-service-deploy-staging/86/prepare-for-deploy-stage/1/prepare-for-deploy-job,
> brxt-core-service-deploy-staging/86/deploy-stage/1/deploy-job,
> brxt-core-service-deploy-staging/86/verify-stage/1/verify-job,
> brxt-config-service-deploy-staging/18/deploy-stage/1/deploy-job,
> brxt-config-service-deploy-production/19/prepare-deploy-stage/1/prepare-deploy-job.
> [go] Received request to create an instance for
> brxt-config-service-deploy-production/19/prepare-deploy-stage/1/prepare-deploy-job
> at 2024-04-09 11:25:39 +00:00
> [go] The number of instances currently running is currently at the maximum
> permissible limit, "2". Not creating more instances for jobs:
> brxt-core-service-deploy-staging/86/prepare-for-deploy-stage/1/prepare-for-deploy-job,
> brxt-core-service-deploy-staging/86/deploy-stage/1/deploy-job,
> brxt-core-service-deploy-staging/86/verify-stage/1/verify-job,
> brxt-config-service-deploy-staging/18/deploy-stage/1/deploy-job,
> 

Re: [Smcwg-public] [External] Draft proposal to add eIDAS QES as vetting evidence for individual

[Clint Wilson via Smcwg-public]

Hi Judith,

As I understand it, the proposed change is purely additive. That is, currently 
there are no approved frameworks in the SBRs meaning that there is no way for a 
compliant CA to rely upon a digital signature as evidence for the collection of 
Individual identity attributes (or any other purpose, I believe, but haven’t 
checked outside of Section 3.2.4.1 as closely). From my reading, this change 
doesn’t eliminate the ability for those not in the EU to trust existing digital 
signatures as evidence as no such ability exists today. Rather, this change 
would only add the ability to rely on digital signatures created by a subset of 
eIDAS Electronic Qualified Signature Certificates. While that is still limited 
in scope, as you indicate, it also doesn’t remove anything already allowed by 
the SBRs.

Can you help me understand better where you see the current SBRs as allowing 
CAs to rely upon digital signatures in the context of 3.2.4.1 today?

Thank you!
-Clint

> On Apr 25, 2024, at 7:20 AM, Judith Spencer via Smcwg-public 
>  wrote:
> 
> Stephen
> My primary concern with the proposed change is that once it finds it’s way 
> into the BR, anyone not in the EU will be eliminated from trusting existing 
> digital signatures as evidence.  For example, here in the U.S., the U.S. 
> Government has an extremely robust digital credential based on a full 
> background check that is independently assessed and accompanied by reams of 
> documentation, regulation and policy.  Over 7 million individuals hold these 
> credentials.  But by this policy, signatures from this community would not be 
> sufficient as evidence.  The CertiPath community, comprised of major 
> Aerospace Corporations, would likewise be eliminated.  While we don’t employ 
> the same level of background checks in our identity proofing, it is certainly 
> based on sound practice and audited annually under WebTrust for CA, which may 
> not be a “national scheme” but is certainly a robust review process widely 
> recognized in the U.S. and Canada.  
> Unless you are prepared to identify schemes that cover all other regions of 
> the world, I believe it is too early to make this change.  As a compromise, I 
> suggest you could identify eIDAS as the qualifying scheme for Europe and 
> remain silent on the rest of the world.  I recommend you revise the opening 
> as follows:
> “If a digital signature is to be used as evidence in the European Union, the 
> CA or RA SHALL only rely upon the following certificate type:”
> Once sufficient assessment has taken place to include all participating 
> regions, the language could be further modified as you suggest.  
> Judy
>  
> Judith Spencer | PMA Chair | CertiPath, Inc.
> 1900 Reston Metro Plaza, Suite 303, Reston, VA 20190
> PH +1.301.974.4227
> Email judith.spen...@certipath.com 
>  
> From: Smcwg-public  On Behalf Of Stephen 
> Davidson via Smcwg-public
> Sent: Wednesday, April 24, 2024 8:06 PM
> To: smcwg-public@cabforum.org
> Subject: [External] [Smcwg-public] Draft proposal to add eIDAS QES as vetting 
> evidence for individual
>  
>  
> Hello all:
>  
> As discussed today, here is draft language for consideration to allow CAs to 
> rely upon signatures created with eIDAS Qualified certificates as evidence 
> supporting validation of individual identity.
> 
> https://github.com/srdavidson/QES-SMIME-BR/blob/master/QES-proposal.md
>  
> I’d be grateful for feedback on this language.
> Best, Stephen
>  
>  
> ___
> Smcwg-public mailing list
> Smcwg-public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/smcwg-public



smime.p7s
Description: S/MIME cryptographic signature
___
Smcwg-public mailing list
Smcwg-public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/smcwg-public

Re: [go-cd] Elastic agents plugin usage

[Chad Wilson]

Can you be specific about the type of elastic agents you are creating and
the plugin you are using. Kubernetes? Docker? Something else? There are
many elastic agent plugins.


> Here's where it gets tricky: when the staging job completes and triggers
> the production job, I expect one of the active agents to take over.
> Instead, the production job attempts to launch new agents, fails due to the
> max count limit, and runs without any agents, leading to failure.
>

I believe elastic agents are generally launched sequentially - i.e a new
one won't be launched until there are no pending-launch ones - but this
depends on the specific elastic agent type.

If you are new to elastic agents, you'll want to be aware that in almost
all elastic agent plugin variants the elastic agents are
single-shot/single-job usage, and are not re-used. The specific type of
elastic agent and its plugin implementation defines how it handles such
things though, so need to know specifics to guess.

Look at the specific elastic agent plugin's log on the server to see what
it is doing. Perhaps your elastic agents are not shutting down
automatically for some reason due to a configuration issue or a problem
with the jobs you are running?

-Chad

-- 
You received this message because you are subscribed to the Google Groups 
"go-cd" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to go-cd+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/go-cd/CAA1RwH9msgAM_RtZu%2BEYbzHoQge5wh62a1i-YV7ueE_KoAkxtQ%40mail.gmail.com.

Re: [go-cd] GOCD server Db issue

[Chad Wilson]

You may have killed GoCD while it was starting up? If you are sure that you
do not have multiple processes accessing the same database at the same time
and it is still stuck, you will have to try manually clearing the lock
.
Backup your database file before doing this.

Need to connect to the database and use this to clear the lock. You'll have
to do so using something like is done here

but *instead
of running an export/import* to recreate the DB you just want to

1) backup the cruise.mv.db file ()
2) find the h2-1.4.200.jar file
3) create clear-liquibase-lock.sql with UPDATE DATABASECHANGELOGLOCK SET
LOCKED=0
4) run something like this on the main DB file java -cp h2-1.4.200.jar
org.h2.tools.RunScript -url jdbc:h2:./cruise -user sa -script
clear-liquibase-lock.sql

-Chad


On Thu, Apr 25, 2024 at 7:22 PM Vijayakumaran A. <
vijayakumara...@praniontech.com> wrote:

> HI Team,
>
> When we restarting gocd server we have below error please advice us. We
> use h2db.
>
> 2024-04-25 16:22:33,896 INFO  [WrapperJarAppMain] Jetty9Server:199 -
> Configuring Jetty using /etc/go/jetty.xml
> 2024-04-25 16:22:33,958 WARN  [WrapperJarAppMain] Server:357 -
> ErrorPageMapper not supported for Server level Error Handling
> 2024-04-25 16:22:34,088 WARN  [WrapperJarAppMain] AbstractHandler:96 - No
> Server set for ResourceHandler@5904a259{STOPPED}
> 2024-04-25 16:22:40,659 WARN  [WrapperJarAppMain] ConnectionManager:117 -
> The file /etc/go/db.properties specified by `go.db.config` does not exist.
> 2024-04-25 16:22:41,319 INFO  [WrapperJarAppMain] DatabaseMigrator:40 -
> Upgrading database, this might take a while depending on the size of the
> database.
> 2024-04-25 16:22:41,320 INFO  [WrapperJarAppMain] DatabaseMigrator:49 -
> 
> 2024-04-25 16:22:41,320 INFO  [WrapperJarAppMain] DatabaseMigrator:49 -
> WARNING: Shutting down your server at this point will lead to a database
> corruption. Please wait until the database upgrade completes.
> 2024-04-25 16:22:41,320 INFO  [WrapperJarAppMain] DatabaseMigrator:49 -
> 
> 2024-04-25 16:27:42,107 ERROR [WrapperJarAppMain] DatabaseMigrator:65 -
> Unable to create database upgrade script for database. The problem was:
> Could not acquire change log lock.  Currently locked by 172.21.0.1
> (172.21.0.1) since 4/25/24, 12:19 PM
> liquibase.exception.LockException: Could not acquire change log lock.
> Currently locked by 172.21.0.1 (172.21.0.1) since 4/25/24, 12:19 PM
>
> --
> You received this message because you are subscribed to the Google Groups
> "go-cd" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to go-cd+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/go-cd/a1b7a304-1559-441e-b002-b385ae93184en%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"go-cd" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to go-cd+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/go-cd/CAA1RwH_UXfcQVRzEoksuCSCKvjPAvQ3%3D%2BmDm35ZLqHtwgK%2Bz_Q%40mail.gmail.com.

[lustre-discuss] Eternally Invalid Lock?

[Ellis Wilson via lustre-discuss]

Hi all,

(This is on 2.15.4 with very limited modifications, none to speak of in ldlm or 
similar)

Very rarely, when attempting to perform an lctl barrier_freeze, we run into a 
situation where it fails with EINVAL.  At that point all future lctl barrier 
operations (including rescan) return EINVAL, except barrier_status, which 
simply shows failed.  This remains stuck that way until we reboot the MDS or we 
reach heat death of the universe.  We have only tested the former solution, and 
that does work, though it's extremely heavyweight.

Since we've been able to repro this on a test system (so we're leaving it in 
that state), we've been able to collect traces, and we see these two that are 
quite interesting:

0001:0001:7.0:1713898822.714580:0:2921:0:(ldlm_lockd.c:2382:ldlm_callback_handler())
 callback on lock 0x831100496f36c2f4 - lock disappeared
0001:0001:4.0:1713898822.710567:0:2676:0:(ldlm_lockd.c:2286:ldlm_callback_errmsg())
 @@@ Operate with invalid parameter, NID=12345-0@lo lock=0x831100496f36c2f4: rc 
= 0  req@2ae045d9 x1783750461943232/t0(0) 
o106->8afc7dcc-fc22-4bb8-8ca1-b5df01779cf4@0@lo:64/0 lens 400/224 e 0 to 0 dl 
1713899139 ref 1 fl Interpret:/0/0 rc -22/-22 job:''

This seems to correlate with this code:
2390 /*
2391  * Force a known safe race, send a cancel to the server for a lock
2392  * which the server has already started a blocking callback on.
2393  */
2394 if (OBD_FAIL_CHECK(OBD_FAIL_LDLM_CANCEL_BL_CB_RACE) &&
2395 lustre_msg_get_opc(req->rq_reqmsg) == LDLM_BL_CALLBACK) {
2396 rc = ldlm_cli_cancel(_req->lock_handle[0], 0);
2397 if (rc < 0)
2398 CERROR("ldlm_cli_cancel: %d\n", rc);
2399 }
2400
2401 lock = ldlm_handle2lock_long(_req->lock_handle[0], 0);
2402 if (!lock) {
2403 CDEBUG(D_DLMTRACE,
2404"callback on lock %#llx - lock disappeared\n",
2405dlm_req->lock_handle[0].cookie);
2406 rc = ldlm_callback_reply(req, -EINVAL);
2407 ldlm_callback_errmsg(req, "Operate with invalid 
parameter", rc,
2408  _req->lock_handle[0]);
2409 RETURN(0);
2410 }

The weird thing is that this lock never expires.  0x831100496f36c2f4 is here to 
stay.  Attempting to clear it by setting clear on the lru_size setting does 
nothing.

Practical questions:
1. I'm assuming NID=12345-0@lo is basically equivalent to "localhost" for 
Lustre, but if it's not, let me know.  I see the first part of this is defined 
as LNET_PID_LUSTRE, though I'm not 100% sure what PID here stands for (I doubt 
process ID?)
2. Is there any tool I can't find to instruct Lustre to drop a lock by ID?  
That'd be handy, though I realize I'm asking for a "turn off airbags" button.
3. One of my engineers made the following comment in case it is helpful:
"It appears that the "lock disappeared" lock exists in the dump_namespaces 
output as the remote end of another lock but nowhere as a lock itself. It's 
also interesting that it seems like the same resource appears twice with 
different resource IDs but the same 3 part ID that looks like a FID:
0001:0001:10.0:1713987044.511342:0:1897178:0:(ldlm_resource.c:1783:ldlm_resource_dump())
 --- Resource: [0x736665727473756c:0x5:0x0].0x0 (c3f4ce61) refcount = 3
0001:0001:10.0:1713987044.511343:0:1897178:0:(ldlm_resource.c:1787:ldlm_resource_dump())
 Granted locks (in reverse order):
0001:0001:10.0:1713987044.511343:0:1897178:0:(ldlm_resource.c:1790:ldlm_resource_dump())
 ### ### ns: MGS lock: e2096801/0x831100496f36eea6 lrc: 2/0,0 mode: 
CR/CR res: [0x736665727473756c:0x5:0x0].0x0 rrc: 4 type: PLN flags: 
0x40 nid: 0@lo remote: 0x831100496f36ee9f expref: 14 pid: 2699 
timeout: 0 lvb_type: 0
0001:0040:10.0:1713987044.511344:0:1897178:0:(ldlm_resource.c:1600:ldlm_resource_putref())
 putref res: c3f4ce61 count: 3
0001:0001:10.0:1713987044.511344:0:1897178:0:(ldlm_resource.c:1790:ldlm_resource_dump())
 ### ### ns: MGS lock: 1007e670/0x831100496f36c2fb lrc: 2/0,0 mode: 
CR/CR res: [0x736665727473756c:0x5:0x0].0x0 rrc: 4 type: PLN flags: 
0x40 nid: 0@lo remote: 0x831100496f36c2f4 expref: 14 pid: 2700 
timeout: 0 lvb_type: 0
0001:0040:10.0:1713987044.511345:0:1897178:0:(ldlm_resource.c:1600:ldlm_resource_putref())
 putref res: c3f4ce61 count: 3
0001:0040:10.0:1713987044.511346:0:1897178:0:(ldlm_resource.c:1600:ldlm_resource_putref())
 putref res: c3f4ce61 count: 2
0001:0040:10.0:1713987044.511346:0:1897178:0:(ldlm_resource.c:1566:ldlm_resource_getref())
 getref res: 1ab54d34 count: 35

0001:0001:10.0:1713987044.512238:0:1897178:0:(ldlm_resource.c:1783:ldlm_resource_dump())
 --- Resource: [0x736665727473756c:0x5:0x0].0x0 (19b90cb9) 

Re: [cabfpub] CABG: Follow-up actions to the creation of the new Definitions and Glossary Working Group

[Clint Wilson via Public]

Apple would like to participate in the Definitions and Glossary Working Group 
(DGWG).

> On Apr 22, 2024, at 9:27 AM, Dimitris Zacharopoulos (HARICA) via Public 
>  wrote:
>
>
> Dear Members,
>
> I have added the approved Charter of the Definitions and Glossary Working 
> Group (DGWG) to the main GitHub Forum repository 
> https://github.com/cabforum/forum/blob/main/DGWG-Charter.md.
>
> I welcome Tim Hollebeek (Chair) and Tim Callan (Vice-Chair) to coordinate 
> with the Infrastructure Subcommittee to create the necessary mailing lists, 
> area in the cabforum.org Public Website and possibly a separate area in the 
> Member's Website (wiki.cabforum.org).
>
> According to the Bylaws and IPR Policy, each Member must declare its 
> participation to the DGWG, preferably by replying to this email so the 
> declaration can be registered on the Public Mailing List.
>
>
> Best regards,
>
> Dimitris Zacharopoulos
> CA/B Forum Chair
> ___
> Public mailing list
> Public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/public



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

Re: [Servercert-wg] [EXTERNAL] Re: Discussion Period Begins - Ballot SC-071: Subscriber Agreement and Terms of Use Consolidation

[Ben Wilson via Servercert-wg]

I removed it because I didn't like the phrasing. I can propose other
wording for an effective date, unless anyone else wants to take a crack at
it.

On Wed, Apr 24, 2024, 1:59 AM Wayne Thayer  wrote:

> Thanks Ben!
>
> The second commit you linked removes the effective date for CP/CPS updates
> from section 9.6.3. While I'm not convinced that this is necessary, it
> seems to add some clarity. Was that paragraph meant to remain in place? If
> not, what is the reasoning?
>
> Otherwise I am also happy with these changes.
>
> - Wayne
>
> On Tue, Apr 23, 2024 at 4:21 PM Aaron Gable via Servercert-wg <
> servercert-wg@cabforum.org> wrote:
>
>> Hi Ben,
>>
>> Thank you! I believe those combine with the previous commits to produce
>> this redline, which looks good to me:
>>
>> https://github.com/cabforum/servercert/compare/41f01640748fa612386f8b1a3031cd1bff3d4f35...682488a832db5b6b4fcdd4cd7cbd86ae9541453e
>>
>> Aaron
>>
>>
>> On Tue, Apr 23, 2024 at 4:25 AM Ben Wilson  wrote:
>>
>>> Dimitris, Aaron, Wayne, and Others,
>>> We are working on improving the language of the ballot.
>>> Here are a couple of versions for you to review and provide feedback on.
>>> https://github.com/cabforum/servercert/commit/d0d962e04bd81a71ebf71a7c45a015cbc75ac979
>>>
>>>
>>> https://github.com/cabforum/servercert/commit/682488a832db5b6b4fcdd4cd7cbd86ae9541453e
>>> Thanks,
>>> Ben
>>>
>>>
>>> On Sun, Apr 21, 2024 at 8:29 PM Dustin Hollenback via Servercert-wg <
>>> servercert-wg@cabforum.org> wrote:
>>>
>>>> Thank you all for the great feedback! We’ll take this offline and
>>>> re-work it based on the input.
>>>>
>>>>
>>>>
>>>> *From:* Servercert-wg  *On Behalf
>>>> Of *Dimitris Zacharopoulos (HARICA) via Servercert-wg
>>>> *Sent:* Sunday, April 21, 2024 1:24 AM
>>>> *To:* Aaron Gable ; CA/B Forum Server
>>>> Certificate WG Public Discussion List 
>>>> *Subject:* [EXTERNAL] Re: [Servercert-wg] Discussion Period Begins -
>>>> Ballot SC-071: Subscriber Agreement and Terms of Use Consolidation
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 19/4/2024 9:54 μ.μ., Aaron Gable wrote:
>>>>
>>>> On Fri, Apr 19, 2024 at 11:07 AM Dimitris Zacharopoulos (HARICA) via
>>>> Servercert-wg  wrote:
>>>>
>>>> What happens if the SA/ToS document changes? I had the impression that
>>>> the ACME client would be able to see the new version and ask that the
>>>> updated version is accepted. How does this process work in practice?
>>>>
>>>>
>>>>
>>>> The ACME protocol itself only has one mechanism for updating the Terms
>>>> of Service: respond to all requests with HTTP 403 Forbidden, error type
>>>> "urn:ietf:params:acme:error:userActionRequired", and a link to a URL where
>>>> a human can take action to agree to the new terms. Breaking every single
>>>> ACME client until their operator takes manual action on a webpage is
>>>> unacceptable and unrealistic, so ACME server operators do not actually do
>>>> this.
>>>>
>>>>
>>>> The ACME protocol was designed to support popular use cases promoting
>>>> automation. The level of automation can be decided by the Applicant. For
>>>> example, if an Applicant chooses the dns-01 challenge and wants to manually
>>>> update their DNS server to include the challenge, so be it. That doesn't
>>>> mean that this breaks every single ACME client. It's supposed to be a
>>>> feature, not a bug :-)
>>>>
>>>> My point is that if an Applicant wants to automate the response to a
>>>> new Terms of Service, they can program the ACME client to connect to the
>>>> return URL with the new document, accept it and continue with the request.
>>>>
>>>>
>>>>
>>>>
>>>> However, this is preceded by one caveat: RFC 8555 Section 7.3.3 says
>>>> "If the server has changed its terms of service since a client
>>>> initially accepted, *and the server is unwilling to process a request
>>>> without explicit agreement to the new terms*, ...".
>>>>
>>>>
>>>>
>>>> So there's an easy path forward: include language in the Subscriber
>>>> Agreement to the effect of "this agreement may be updated&q

Re: [cabf_netsec] Voting Period Begins | Ballot NS-003: Restructure the NCSSRs

[Ben Wilson via Netsec]

Mozilla votes "yes" on this ballot.

On Tue, Apr 23, 2024, 5:59 PM Clint Wilson via Netsec 
wrote:

> Ballot NS-003 is proposed by Clint Wilson of Apple and endorsed by Trevoli
> Ponds-White of Amazon and David Kluge of Google Trust Services.
>
> *Purpose of Ballot*
>
> This ballot proposes a comprehensive restructuring of the Network and
> Certificate System Security Requirements (NCSSRs), excepting Section 4. The
> current structure of the document has proven to be challenging for creating
> ballots, contains duplicated requirements, and separates similar
> requirements across the document. These issues have led to inefficiencies
> in managing and implementing security standards. Therefore, this proposal
> aims to streamline the document's structure, eliminate redundancies,
> improve comprehensibility, and enhance clarity and coherence.
>
> *Reasons for Proposal:*
>
>
>- *Complexity in Ballot Creation*: The current document structure can
>make it difficult to create and manage ballots efficiently, leading to
>somewhat awkward updating processes, abandoned ballots, and a lack of
>confidence that ballots effect the intended changes.
>- *Redundancy*: Over time, some parts of the NCSSRs have touched on
>the same topic, leading to some duplication across the document and further
>to confusion and inconsistency in implementation.
>- *Fragmentation*: Similar requirements for different parts of a CA’s
>NCSSR-relevant infrastructure are scattered throughout the document, making
>it somewhat more difficult for to locate and comprehend a complete picture
>of these requirements effectively.
>- *Minor Issues*: The document contains other, more minor issues that
>also impede its usability and effectiveness, such as missing definitions,
>unclear list structures, and requirements that are more optional than they
>may currently appear.
>
>
> *Benefits of the Updated Document Structure:*
>
>
>- *Enhanced Clarity*: The revised structure should improve the clarity
>and coherence of the document, making the requirements it represents easier
>to understand, as well as result in greater consistency when implementing
>or assessing its security requirements.
>- *Future Updates*: A more granular document structure should improve
>the process of creating and managing ballots in the future. Similarly, the
>improved proximity of related requirements should hopefully aid in
>identifying the areas the NCSSRs can most benefit from further attention.
>- *Grouping and De-duplication of Similar Requirements*: By
>consolidating duplicated requirements, the updated document should make it
>much easier to find, comprehend, assess, and implement related 
> requirements.
>- *Clearer Recommendations*: The updated document includes a number of
>additional “SHOULD”-type stipulations, clarifying some of the language in
>the current NCSSRs such that it’s easier to identify where the NCSSRs
>impose a strict requirement as opposed to a strong recommendation.
>
>
> Overall, this ballot proposal seeks to address existing challenges in
> updating the current version of the NCSSRs and pave the way for future
> improvements to the NCSSRs.
>
> *MOTION BEGINS*
>
> This ballot modifies the “Network and Certificate System Security
> Requirements” as follows, based on version 1.7:
>
>
> https://github.com/cabforum/netsec/compare/c62a2f88e252de5c79b101fa3c9e9c536388639a...8bd66d27c07e30d1f4d9e6dd57b075bca499bf2e
>
> *MOTION ENDS*
>
> The procedure for approval of this ballot is as follows:
>
> *Discussion Period* (14+ days)
>
> Start Time: 2024-April-09 16:00 UTC
> End Time: 2024-April-23 15:59 UTC
>
> *Voting Period* (7 days)
>
> Start Time: 2024-April-23 16:00 UTC
> End Time: 2024-April-30 16:00 UTC
> ___
> Netsec mailing list
> Netsec@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/netsec
>
___
Netsec mailing list
Netsec@cabforum.org
https://lists.cabforum.org/mailman/listinfo/netsec

[cabf_netsec] Voting Period Begins | Ballot NS-003: Restructure the NCSSRs

[Clint Wilson via Netsec]

Ballot NS-003 is proposed by Clint Wilson of Apple and endorsed by Trevoli 
Ponds-White of Amazon and David Kluge of Google Trust Services.

Purpose of Ballot

This ballot proposes a comprehensive restructuring of the Network and 
Certificate System Security Requirements (NCSSRs), excepting Section 4. The 
current structure of the document has proven to be challenging for creating 
ballots, contains duplicated requirements, and separates similar requirements 
across the document. These issues have led to inefficiencies in managing and 
implementing security standards. Therefore, this proposal aims to streamline 
the document's structure, eliminate redundancies, improve comprehensibility, 
and enhance clarity and coherence.

Reasons for Proposal:

Complexity in Ballot Creation: The current document structure can make it 
difficult to create and manage ballots efficiently, leading to somewhat awkward 
updating processes, abandoned ballots, and a lack of confidence that ballots 
effect the intended changes.
Redundancy: Over time, some parts of the NCSSRs have touched on the same topic, 
leading to some duplication across the document and further to confusion and 
inconsistency in implementation.
Fragmentation: Similar requirements for different parts of a CA’s 
NCSSR-relevant infrastructure are scattered throughout the document, making it 
somewhat more difficult for to locate and comprehend a complete picture of 
these requirements effectively.
Minor Issues: The document contains other, more minor issues that also impede 
its usability and effectiveness, such as missing definitions, unclear list 
structures, and requirements that are more optional than they may currently 
appear.

Benefits of the Updated Document Structure:

Enhanced Clarity: The revised structure should improve the clarity and 
coherence of the document, making the requirements it represents easier to 
understand, as well as result in greater consistency when implementing or 
assessing its security requirements.
Future Updates: A more granular document structure should improve the process 
of creating and managing ballots in the future. Similarly, the improved 
proximity of related requirements should hopefully aid in identifying the areas 
the NCSSRs can most benefit from further attention.
Grouping and De-duplication of Similar Requirements: By consolidating 
duplicated requirements, the updated document should make it much easier to 
find, comprehend, assess, and implement related requirements.
Clearer Recommendations: The updated document includes a number of additional 
“SHOULD”-type stipulations, clarifying some of the language in the current 
NCSSRs such that it’s easier to identify where the NCSSRs impose a strict 
requirement as opposed to a strong recommendation.

Overall, this ballot proposal seeks to address existing challenges in updating 
the current version of the NCSSRs and pave the way for future improvements to 
the NCSSRs.

MOTION BEGINS

This ballot modifies the “Network and Certificate System Security Requirements” 
as follows, based on version 1.7:

https://github.com/cabforum/netsec/compare/c62a2f88e252de5c79b101fa3c9e9c536388639a...8bd66d27c07e30d1f4d9e6dd57b075bca499bf2e

MOTION ENDS

The procedure for approval of this ballot is as follows:

Discussion Period (14+ days)

Start Time: 2024-April-09 16:00 UTC
End Time: 2024-April-23 15:59 UTC

Voting Period (7 days)

Start Time: 2024-April-23 16:00 UTC
End Time: 2024-April-30 16:00 UTC

smime.p7s
Description: S/MIME cryptographic signature
___
Netsec mailing list
Netsec@cabforum.org
https://lists.cabforum.org/mailman/listinfo/netsec

Re: [Servercert-wg] [EXTERNAL] Re: Discussion Period Begins - Ballot SC-071: Subscriber Agreement and Terms of Use Consolidation

[Ben Wilson via Servercert-wg]

Dimitris, Aaron, Wayne, and Others,
We are working on improving the language of the ballot.
Here are a couple of versions for you to review and provide feedback on.
https://github.com/cabforum/servercert/commit/d0d962e04bd81a71ebf71a7c45a015cbc75ac979

https://github.com/cabforum/servercert/commit/682488a832db5b6b4fcdd4cd7cbd86ae9541453e
Thanks,
Ben


On Sun, Apr 21, 2024 at 8:29 PM Dustin Hollenback via Servercert-wg <
servercert-wg@cabforum.org> wrote:

> Thank you all for the great feedback! We’ll take this offline and re-work
> it based on the input.
>
>
>
> *From:* Servercert-wg  *On Behalf Of 
> *Dimitris
> Zacharopoulos (HARICA) via Servercert-wg
> *Sent:* Sunday, April 21, 2024 1:24 AM
> *To:* Aaron Gable ; CA/B Forum Server Certificate
> WG Public Discussion List 
> *Subject:* [EXTERNAL] Re: [Servercert-wg] Discussion Period Begins -
> Ballot SC-071: Subscriber Agreement and Terms of Use Consolidation
>
>
>
>
>
> On 19/4/2024 9:54 μ.μ., Aaron Gable wrote:
>
> On Fri, Apr 19, 2024 at 11:07 AM Dimitris Zacharopoulos (HARICA) via
> Servercert-wg  wrote:
>
> What happens if the SA/ToS document changes? I had the impression that the
> ACME client would be able to see the new version and ask that the updated
> version is accepted. How does this process work in practice?
>
>
>
> The ACME protocol itself only has one mechanism for updating the Terms of
> Service: respond to all requests with HTTP 403 Forbidden, error type
> "urn:ietf:params:acme:error:userActionRequired", and a link to a URL where
> a human can take action to agree to the new terms. Breaking every single
> ACME client until their operator takes manual action on a webpage is
> unacceptable and unrealistic, so ACME server operators do not actually do
> this.
>
>
> The ACME protocol was designed to support popular use cases promoting
> automation. The level of automation can be decided by the Applicant. For
> example, if an Applicant chooses the dns-01 challenge and wants to manually
> update their DNS server to include the challenge, so be it. That doesn't
> mean that this breaks every single ACME client. It's supposed to be a
> feature, not a bug :-)
>
> My point is that if an Applicant wants to automate the response to a new
> Terms of Service, they can program the ACME client to connect to the return
> URL with the new document, accept it and continue with the request.
>
>
>
>
> However, this is preceded by one caveat: RFC 8555 Section 7.3.3 says "If
> the server has changed its terms of service since a client
> initially accepted, *and the server is unwilling to process a request
> without explicit agreement to the new terms*, ...".
>
>
>
> So there's an easy path forward: include language in the Subscriber
> Agreement to the effect of "this agreement may be updated", and always be
> willing to process requests without explicit agreement to the new terms. At
> a glance, Let's Encrypt, Google Trust Services, GoDaddy, and HARICA all
> take this approach in their Subscriber Agreement documents.
>
>
>
> So I think there are two potential issues with the proposed language:
>
> 1) "The Certificate Warranties specifically include [that]... the
> Subscriber has been provided with the most current version of the
> Subscriber Agreement" -- I think this language is *probably* fine, as
> long as "posted to the CA's policy document repository" counts as
> "provided". But I'd prefer not to have to split hairs, and so would prefer
> language which more clearly makes it obvious that the updated document does
> not have to proactively be given to each Subscriber individually and that
> simply posting it to the public repository is sufficient.
>
>
> In some cases, CAs point to a URL that contains the latest version of the
> Subscriber Agreement, so in one sense the Applicant agrees to that -latest-
> version without the need to see a different URL. The only concern here is
> what happens to implementations where the Applicant accepts the Subscriber
> Agreement at account creation and not at Certificate Issuance/Retrieval. In
> that scenario, the CA would not be able to claim that the Applicant has
> accepted the updated version, right?
>
>
> 2) "The Certificate Warranties specifically include [that]... the
> applicable Subscriber Agreement is the Subscriber Agreement that was
> accepted when the Certificate was issued" -- Again, this language is
> probably technically fine, in that the Subscriber Agreement can include
> language saying that Subscribers are assumed to have accepted future
> updates to the document. But I'd still prefer not to split hairs, and so I
> think that Wayne's suggestion of "...that was *in force* when the
> Certificate was issued" is a good one.
>
>
> I also prefer this language but would that address the concern mentioned
> above?
>
>
>
>
> Unrelated to the discussion above, our Counsel has suggested one other
> simplification of the language in the ballot: "if the CA and Subscriber are
> not Affiliated, the Subscriber and CA 

[Metamath] Question abouot indistopon

['B. Wilson' via Metamath]

The A e. V antecedent is confusing me. Might I ask for a quick pointer?

85195 indistopon $p |- ( A e. V -> { (/) , A } e. ( TopOn ` A ) ) $= ... $.

It looks suspiciously close to A e. _V which reas as "A is a set", but in this
case the V is just floating. What are the semantics here?

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/3UBII6CP7S76N.3E59KU168XFGI%40wilsonb.com.

[Wikitech-ambassadors] Tech News 2024, week 17

[Nick Wilson (Quiddity)]

The latest technical newsletter is now available at
https://meta.wikimedia.org/wiki/Special:MyLanguage/Tech/News/2024/17 -
Below is the English version.
You can help write the next newsletter: Whenever you see information about
Wikimedia technology that you think should be distributed more broadly, you
can add it to the next newsletter at
https://meta.wikimedia.org/wiki/Tech/News/Next .
More information on how to contribute is available. You can also contact me
directly.
As always, feedback (on- or off-list) is appreciated and encouraged.
——
Other languages: Bahasa Indonesia
, Deutsch
, English, Ghanaian
Pidgin , Tiếng Việt
, français
, italiano
, norsk bokmål
, polski
, čeština
, русский
, українська
, עברית
, العربية
, فارسی
, বাংলা
, 中文


Latest *tech news
* from the
Wikimedia technical community. Please tell other users about these changes.
Not all changes will affect you. Translations
 are
available.

*Recent changes*

   - Starting this week, newcomers editing Wikipedia will be encouraged
   

   to try structured tasks. Structured tasks
   

   have been shown to improve newcomer activation and retention
   
.
   [1] 
   - You can nominate your favorite tools
   
   for the fifth edition of the Coolest Tool Award. Nominations will be open
   until May 10.

*Changes later this week*

   - The new version 
   of MediaWiki will be on test wikis and MediaWiki.org from 23 April. It will
   be on non-Wikipedia wikis and some Wikipedias from 24 April. It will be on
   all wikis from 25 April (calendar
   ). [2]
   [3]
   

*Future changes*

   - This is the last warning that by the end of May 2024 the Vector 2022
   skin will no longer share site and user scripts/styles with old Vector. For
   user-scripts that you want to keep using on Vector 2022, copy the contents
   of Special:MyPage/vector.js
    to
   Special:MyPage/vector-2022.js
   . There
   are more technical details
   

   available. Interface administrators who foresee this leading to lots of
   technical support questions may wish to send a mass message to your
   community, as was done on French Wikipedia. [4]
   

*Tech news 
prepared by Tech News writers
 and
posted by bot

•
Contribute
 •
Translate
 •
Get help  • Give feedback
 • Subscribe or unsubscribe
.*
___
Wikitech-ambassadors mailing list -- wikitech-ambassadors@lists.wikimedia.org
To unsubscribe send an email to wikitech-ambassadors-le...@lists.wikimedia.org

[Translators-l] Re: Tech News #17, 2024

[Nick Wilson (Quiddity)]

Thank you all for your help! It is deeply appreciated. The newsletter has
now been delivered (in 17 languages) to 1,114 pages.

Plus, extra thanks to Tacsipacsi for creating
https://meta.wikimedia.org/wiki/Template:Tech_news_text
___
Translators-l mailing list -- translators-l@lists.wikimedia.org
To unsubscribe send an email to translators-l-le...@lists.wikimedia.org

Re: [cabfpub] CABG: Follow-up actions to the creation of the new Definitions and Glossary Working Group

[Ben Wilson via Public]

Mozilla wants to participate in the new Definitions and Glossary Working
Group.

On Mon, Apr 22, 2024 at 10:27 AM Dimitris Zacharopoulos (HARICA) via Public
 wrote:

>
> Dear Members,
>
> I have added the approved Charter of the Definitions and Glossary
> Working Group (DGWG) to the main GitHub Forum repository
> https://github.com/cabforum/forum/blob/main/DGWG-Charter.md.
>
> I welcome Tim Hollebeek (Chair) and Tim Callan (Vice-Chair) to
> coordinate with the Infrastructure Subcommittee to create the necessary
> mailing lists, area in the cabforum.org Public Website and possibly a
> separate area in the Member's Website (wiki.cabforum.org).
>
> According to the Bylaws and IPR Policy, each Member must declare its
> participation to the DGWG, preferably by replying to this email so the
> declaration can be registered on the Public Mailing List.
>
>
> Best regards,
>
> Dimitris Zacharopoulos
> CA/B Forum Chair
> ___
> Public mailing list
> Public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/public
>
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

Re: [cabfpub] Draft Charter for IPR Subcommittee

[Ben Wilson via Public]

All,

Here is a revised Charter for the Forum IPR Subcommittee ("FIPR").

https://github.com/BenWilson-Mozilla/forum/blob/fipr-charter/FIPR-Charter.md

Thanks,

Ben

On Fri, Apr 19, 2024 at 11:59 AM Dimitris Zacharopoulos (HARICA) via Public
 wrote:

> Hi  Ben,
>
> On 16/4/2024 7:48 μ.μ., Ben Wilson via Public wrote:
>
> All,
>
> As mentioned during the Forum teleconference of April 11, 2024, here is a
> draft charter for a Forum IPR Subcommittee. (This effort is separate, but
> somewhat in parallel to the work of the Patent Advisory Group, which will
> be handling GoDaddy's Patent Exclusion Notice, filed Mar. 22, 2024, in
> relation to Ballot SC-70.)
>
> Please provide your comments or questions.
>
> Thanks,
>
> Ben
>
>
>
> *Forum IPR Subcommittee Charter*
>
> Upon approval of the CAB Forum by ballot in accordance with section 5.6 of
> the Bylaws, the Forum IPR Subcommittee (“FIS”) is created to perform the
> activities as specified in this Charter, subject to the terms and
> conditions of the CA/Browser Forum Bylaws and Intellectual Property Rights
> (IPR) Policy, as such documents may change from time to time. The
> definitions found in the Forum’s Bylaws or IPR Policy shall apply to
> capitalized terms in this Charter.
>
>
> I'm not sure the IPR Policy needs to be invoked here. Please take a look
> at the Forum Infrastructure SC charter (
> https://cabforum.org/2019/10/08/ballot-forum-10-re-charter-forum-infrastructure-working-group/).
> Also, is it ok to use the acronym "FIS" as it is also referred in the Forum
> Subcommittee Charter?
>
> *Scope*
>
> The primary activity of the FIS shall be to review, and propose revisions
> to, the Forum’s IPR Policy, IPR Policy Agreement, exclusion notice
> template, and similar documents.  The FIS may perform other activities
> ancillary to this primary activity.  The FIS will not create Final
> Guidelines or Final Maintenance Guidelines.
>
>
> Based on the last statement, I don't think we need to mention that this
> charter is subject to the IPR Policy.
>
> *Anticipated End Date*
>
> The FIS is chartered without a specific end date. However, it is expected
> that the FIS will deliver results of its initial work to the Forum prior to
> _ 2024.  Thereafter, the FIS will continue to exist, but may be
> dissolved at any time by Forum ballot.
>
>
> If the Subcommittee completes its deliverables and those deliverables are
> accepted by the Forum by ballot, the subcommittee should probably be
> dissolved automatically. We could renew its charter or duration if we find
> something else useful but based on the current expectations it looks like
> it will be dissolved if the proposed documents are approved.
>
> *Initial Chairs and Contacts*
>
> The proposer of the ballot adopting this Charter, Ben Wilson, will act as
> organizer of the FIS until the first teleconference is held for the FIS, at
> which time the FIS will elect a chair and vice-chair, either by vote or by
> acclamation of those present. The chair and vice-chair will normally serve
> two-year terms.  However, the first term will start upon their election
> and run through 31 October 2026.
>
> *Members Eligible to Participate*
>
> The FIS welcomes the participation of any Member organization of the Forum
> interested in this work.  Forum Members that have initially declared
> their participation in this Subcommittee are:
>
> Amazon, Apple, DigiCert, GoDaddy, Google, HARICA, Let’s Encrypt, Mozilla,
> Sectigo, SwissSign,
>
> *Voting and Voting Structure*
>
> Voting in the FIS shall be limited to Forum members. Voting shall be
> egalitarian: all Members shall vote together as a single class, with one
> vote granted to each Member organization. Any decisions of the FIS needed
> to be voted upon by the FIS shall be considered adopted if the number of
> votes in favor exceeds 50% of the votes cast.
>
>
> This is not a WG so no voting or voting structure is necessary.
>
> *Primary Means of Communication*
>
> The FIS will communicate primarily through listserv-based email and shall
> conduct periodic calls or face-to-face meetings as needed.
>
>
> I suggest we combine some elements from
> https://cabforum.org/2019/10/08/ballot-forum-10-re-charter-forum-infrastructure-working-group/
> to improve this charter.
>
> Thanks Ben for putting this together!
>
> Dimitris.
>
>
>
> ___
> Public mailing 
> listPublic@cabforum.orghttps://lists.cabforum.org/mailman/listinfo/public
>
>
> ___
> Public mailing list
> Public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/public
>
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

Re: [cabfpub] Draft Charter for IPR Subcommittee

[Ben Wilson via Public]

Thanks, Dimitris.

I will make edits to the proposal and get back to everyone.

Ben

On Fri, Apr 19, 2024 at 11:59 AM Dimitris Zacharopoulos (HARICA) via Public
 wrote:

> Hi  Ben,
>
> On 16/4/2024 7:48 μ.μ., Ben Wilson via Public wrote:
>
> All,
>
> As mentioned during the Forum teleconference of April 11, 2024, here is a
> draft charter for a Forum IPR Subcommittee. (This effort is separate, but
> somewhat in parallel to the work of the Patent Advisory Group, which will
> be handling GoDaddy's Patent Exclusion Notice, filed Mar. 22, 2024, in
> relation to Ballot SC-70.)
>
> Please provide your comments or questions.
>
> Thanks,
>
> Ben
>
>
>
> *Forum IPR Subcommittee Charter*
>
> Upon approval of the CAB Forum by ballot in accordance with section 5.6 of
> the Bylaws, the Forum IPR Subcommittee (“FIS”) is created to perform the
> activities as specified in this Charter, subject to the terms and
> conditions of the CA/Browser Forum Bylaws and Intellectual Property Rights
> (IPR) Policy, as such documents may change from time to time. The
> definitions found in the Forum’s Bylaws or IPR Policy shall apply to
> capitalized terms in this Charter.
>
>
> I'm not sure the IPR Policy needs to be invoked here. Please take a look
> at the Forum Infrastructure SC charter (
> https://cabforum.org/2019/10/08/ballot-forum-10-re-charter-forum-infrastructure-working-group/).
> Also, is it ok to use the acronym "FIS" as it is also referred in the Forum
> Subcommittee Charter?
>
> *Scope*
>
> The primary activity of the FIS shall be to review, and propose revisions
> to, the Forum’s IPR Policy, IPR Policy Agreement, exclusion notice
> template, and similar documents.  The FIS may perform other activities
> ancillary to this primary activity.  The FIS will not create Final
> Guidelines or Final Maintenance Guidelines.
>
>
> Based on the last statement, I don't think we need to mention that this
> charter is subject to the IPR Policy.
>
> *Anticipated End Date*
>
> The FIS is chartered without a specific end date. However, it is expected
> that the FIS will deliver results of its initial work to the Forum prior to
> _ 2024.  Thereafter, the FIS will continue to exist, but may be
> dissolved at any time by Forum ballot.
>
>
> If the Subcommittee completes its deliverables and those deliverables are
> accepted by the Forum by ballot, the subcommittee should probably be
> dissolved automatically. We could renew its charter or duration if we find
> something else useful but based on the current expectations it looks like
> it will be dissolved if the proposed documents are approved.
>
> *Initial Chairs and Contacts*
>
> The proposer of the ballot adopting this Charter, Ben Wilson, will act as
> organizer of the FIS until the first teleconference is held for the FIS, at
> which time the FIS will elect a chair and vice-chair, either by vote or by
> acclamation of those present. The chair and vice-chair will normally serve
> two-year terms.  However, the first term will start upon their election
> and run through 31 October 2026.
>
> *Members Eligible to Participate*
>
> The FIS welcomes the participation of any Member organization of the Forum
> interested in this work.  Forum Members that have initially declared
> their participation in this Subcommittee are:
>
> Amazon, Apple, DigiCert, GoDaddy, Google, HARICA, Let’s Encrypt, Mozilla,
> Sectigo, SwissSign,
>
> *Voting and Voting Structure*
>
> Voting in the FIS shall be limited to Forum members. Voting shall be
> egalitarian: all Members shall vote together as a single class, with one
> vote granted to each Member organization. Any decisions of the FIS needed
> to be voted upon by the FIS shall be considered adopted if the number of
> votes in favor exceeds 50% of the votes cast.
>
>
> This is not a WG so no voting or voting structure is necessary.
>
> *Primary Means of Communication*
>
> The FIS will communicate primarily through listserv-based email and shall
> conduct periodic calls or face-to-face meetings as needed.
>
>
> I suggest we combine some elements from
> https://cabforum.org/2019/10/08/ballot-forum-10-re-charter-forum-infrastructure-working-group/
> to improve this charter.
>
> Thanks Ben for putting this together!
>
> Dimitris.
>
>
>
> ___
> Public mailing 
> listPublic@cabforum.orghttps://lists.cabforum.org/mailman/listinfo/public
>
>
> ___
> Public mailing list
> Public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/public
>
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

Re: [cabfpub] Draft Charter for IPR Subcommittee

[Ben Wilson via Public]

Hi Martijn,

I was thinking that there may be miscellaneous decisions where the
Subcommittee might need to vote. There is no intent that the Subcommittee
would be able to "adopt" a new IPR Policy, if that is your concern.

I was proposing that only Forum Members would be eligible to participate on
the Subcommittee, so Associate Members, Probationary Members and Interested
Parties would not be participating on the Subcommittee, nor would they have
a vote.

Thanks,

Ben

On Fri, Apr 19, 2024 at 1:55 AM Martijn Katerbarg <
martijn.katerb...@sectigo.com> wrote:

> Ben, a few questions / clarifications:
>
>
>
> > Voting in the FIS shall be limited to Forum members. Voting shall be
> egalitarian: all Members shall vote together as a single
>
> Does this mean the Subcommittee will run a ballot rather than the Forum,
> or will the Forum still run the actuall ballot?
>
>
>
> > Voting shall be egalitarian: all Members shall vote together as a
> single class
>
> Is the intent here to also allow Associated Members, Probationary Members
> and Interested Parties to vote?
>
> Regards,
>
> Martijn
>
>
>
> *From: *Public  on behalf of Ben Wilson via
> Public 
> *Date: *Thursday, 18 April 2024 at 17:37
> *To: *CA/Browser Forum Public Discussion List 
> *Subject: *Re: [cabfpub] Draft Charter for IPR Subcommittee
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
>
>
> All,
>
> I will put this in ballot format. I am looking for endorsers.
>
> Thanks,
>
> Ben
>
>
>
> On Tue, Apr 16, 2024 at 10:48 AM Ben Wilson  wrote:
>
> All,
>
> As mentioned during the Forum teleconference of April 11, 2024, here is a
> draft charter for a Forum IPR Subcommittee. (This effort is separate, but
> somewhat in parallel to the work of the Patent Advisory Group, which will
> be handling GoDaddy's Patent Exclusion Notice, filed Mar. 22, 2024, in
> relation to Ballot SC-70.)
>
> Please provide your comments or questions.
>
> Thanks,
>
> Ben
>
>
>
> *Forum IPR Subcommittee Charter*
>
> Upon approval of the CAB Forum by ballot in accordance with section 5.6 of
> the Bylaws, the Forum IPR Subcommittee (“FIS”) is created to perform the
> activities as specified in this Charter, subject to the terms and
> conditions of the CA/Browser Forum Bylaws and Intellectual Property Rights
> (IPR) Policy, as such documents may change from time to time. The
> definitions found in the Forum’s Bylaws or IPR Policy shall apply to
> capitalized terms in this Charter.
>
> *Scope*
>
> The primary activity of the FIS shall be to review, and propose revisions
> to, the Forum’s IPR Policy, IPR Policy Agreement, exclusion notice
> template, and similar documents.  The FIS may perform other activities
> ancillary to this primary activity.  The FIS will not create Final
> Guidelines or Final Maintenance Guidelines.
>
> *Anticipated End Date*
>
> The FIS is chartered without a specific end date. However, it is expected
> that the FIS will deliver results of its initial work to the Forum prior to
> _ 2024.  Thereafter, the FIS will continue to exist, but may be
> dissolved at any time by Forum ballot.
>
> *Initial Chairs and Contacts*
>
> The proposer of the ballot adopting this Charter, Ben Wilson, will act as
> organizer of the FIS until the first teleconference is held for the FIS, at
> which time the FIS will elect a chair and vice-chair, either by vote or by
> acclamation of those present. The chair and vice-chair will normally serve
> two-year terms.  However, the first term will start upon their election and
> run through 31 October 2026.
>
> *Members Eligible to Participate*
>
> The FIS welcomes the participation of any Member organization of the Forum
> interested in this work.  Forum Members that have initially declared their
> participation in this Subcommittee are:
>
> Amazon, Apple, DigiCert, GoDaddy, Google, HARICA, Let’s Encrypt, Mozilla,
> Sectigo, SwissSign,
>
> *Voting and Voting Structure*
>
> Voting in the FIS shall be limited to Forum members. Voting shall be
> egalitarian: all Members shall vote together as a single class, with one
> vote granted to each Member organization. Any decisions of the FIS needed
> to be voted upon by the FIS shall be considered adopted if the number of
> votes in favor exceeds 50% of the votes cast.
>
> *Primary Means of Communication*
>
> The FIS will communicate primarily through listserv-based email and shall
> conduct periodic calls or face-to-face meetings as needed.
>
>
>
>
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

Re: For sale Friday, big list to unload

[mike wilson]

> On 19/04/2024 23:25 BST Larry Colen  wrote:
> 
>  
> > On Apr 19, 2024, at 3:10 PM, John Sessoms  wrote:
> > 
> > I believe Cotty is selling gear to raise money to dump into a hole in the 
> > water.
> 
> I dunno why he doesn't save time and effort and just tear up hundred pound 
> notes, in the shower, with his clothes on.

Sadly, we don't have hundred pound notes.  Probably soon...

And our money is plastic these days.  I've never actually tried but I suspect 
that it will not tear as easily as paper and, with wet hands, will be 
impossible to rip.  And you know what they say about taking scissors into the 
shower.
--
%(real_name)s Pentax-Discuss Mail List
To unsubscribe send an email to pdml-le...@pdml.net
to UNSUBSCRIBE from the PDML, please visit the link directly above and follow 
the directions.

[Translators-l] Re: Tech News #17, 2024

[Nick Wilson (Quiddity)]

On Thu, Apr 18, 2024 at 5:40 PM Nick Wilson (Quiddity) <
nwil...@wikimedia.org> wrote:

> The latest tech newsletter is ready for early translation:
> https://meta.wikimedia.org/wiki/Tech/News/2024/17
>
> Direct translation link:
>
> https://meta.wikimedia.org/w/index.php?title=Special:Translate=page-Tech%2FNews%2F2024%2F17=page
>

The text of the newsletter is now final.

Nothing has changed since yesterday.

There won't be any more changes; you can translate safely. Thanks!
___
Translators-l mailing list -- translators-l@lists.wikimedia.org
To unsubscribe send an email to translators-l-le...@lists.wikimedia.org

Re: [blink-dev] Intent to Continue Experimenting: Tabbed Web Apps

[Brett Wilson]

On Wed, Apr 10, 2024 at 8:29 AM Alex Russell 
wrote:

> Great to hear there's support for the feature.
>
> 118-126 w/o breaking changes is pushing things. Is it practical to ship
> inside the 123-126 window? How close are we?\
>

Hi Alex,

Sorry for the delay, we've been trying to figure out the timing for this
feature since there are a bunch of moving parts. We're going to try to get
this into M126 (soon) and are working on the finishing touches. Look for
communication in the coming weeks.

The main reason is that M126 is the ChromeOS Long-Term Support ("LTS")
release used by many companies and schools. The date-based origin trials
interact particularly poorly with the LTS releases, and because this
feature is triggered by a manifest, it can't really be feature-detected for
a fallback like you would normally do for a web trial. As a result, the
options are (1) land in M126, (2) extend the origin trial until M126 LTS
ends in 2025, or (3) inflict brokenness on LTS users.

To answer Stefan's questions:

   - I think this would be a nice feature on all platforms as well, but the
   browser team has not shown interest outside of ChromeOS for now.
   - The thinking behind the lack of favicons is that they would normally
   all be the same which is a bit weird.
   - The active/inactive split should be inherited from the general browser
   tab strip behavior. We have promised not to diverge the presentation from
   the default tab strip to keep the maintenance burden on the team lower
   while re-using the browser tab strip code.

Brett


> On Tuesday, April 9, 2024 at 9:07:37 AM UTC-7 Stefan Peter wrote:
>
>> Hi, I think it would help to extend the Open Trial to Windows and Mac as
>> well. We're really like that feature it fits perfectly our strategy and the
>> behaviour of or App (having mutliple remote session to computers active in
>> different tabs)
>>
>> I have only minor problems with it, like that there are no favicons in
>> the tabs or that the visible split between inactive tabs is not so well
>> visible. But otherwise can't wait to have it as a non experimental feature.
>> :)
>>
>> Domenic Denicola schrieb am Mittwoch, 13. März 2024 um 03:45:58 UTC+1:
>>
>>> LGTM to extend. The recent spec progress looks significant, and other
>>> areas are in good shape.
>>>
>>> On Wed, Mar 13, 2024 at 11:36 AM Matt Giuca  wrote:
>>>
>> The original trial was from 118 to 123, inclusive.

 We want to extend it so it continues running from 124 to 126, inclusive.

 On Fri, 8 Mar 2024 at 16:52, Domenic Denicola 
 wrote:

>>> For what milestones do you want to extend the experiment for?
>
> On Thu, Mar 7, 2024 at 3:39 PM Matt Giuca  wrote:
>
>> Contact emailsloub...@google.com, gle...@chromium.org,
>> mgi...@chromium.org, bre...@chromium.org
>>
>
>>
>> Explainer
>> https://github.com/WICG/manifest-incubations/blob/gh-pages/tabbed-mode-explainer.md
>>
>> Specificationhttps://github.com/WICG/manifest-incubations/pull/95
>>  (draft)
>>
>> Summary
>>
>> Allow web app windows to have a tab strip. This adds a new display
>> mode "tabbed" and a new manifest field to allow customizations to the tab
>> strip.
>>
>> Following a 6-milestone origin trial, we would like to continue
>> experimenting as the feature team is not ready to commit to shipping, and
>> gathered very little data from the initial experiment (as partners we 
>> have
>> lined up have not yet started their experiment).
>>
>> Per the Blink policy, we have made substantial progress in these five
>> areas:
>>
>>- Draft spec: https://github.com/WICG/manifest-incubations/pull/95
>>- TAG review: https://github.com/w3ctag/design-reviews/issues/841
>>(closed with "unsatisfied"; I have sent a follow-up comment).
>>- Signals requests:
>>   - WebKit:
>>   https://github.com/WebKit/standards-positions/issues/195
>>   (ignored)
>>   - Mozilla:
>>   https://github.com/mozilla/standards-positions/issues/811
>>   (closed as not interested in any of "these sorts of features")
>>- Outreach for feedback from spec community:
>>https://developer.chrome.com/docs/capabilities/tabbed-application-mode
>>- WPT tests:
>>
>> https://github.com/web-platform-tests/wpt/blob/master/appmanifest/display-override-member/display-override-member-media-feature-tabbed-manual.tentative.html
>>
>> Blink componentBlink>AppManifest
>> 
>>
>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/841
>>
>> TAG review statusClosed ("Unsatisfied")
>>
>> Chromium Trial NameWebAppTabStrip
>>
>> Origin trial feedback summary
>> Only a small number of signups, most look like individuals wanting to
>> experiment. A handful of 

[Translators-l] Tech News #17, 2024

[Nick Wilson (Quiddity)]

The latest tech newsletter is ready for early translation:
https://meta.wikimedia.org/wiki/Tech/News/2024/17

Direct translation link:
https://meta.wikimedia.org/w/index.php?title=Special:Translate=page-Tech%2FNews%2F2024%2F17=page

We plan to send the newsletter on Monday afternoon (UTC), i.e. Monday
morning PT. The existing translations will be posted on the wikis in
that language. Deadlines:
https://meta.wikimedia.org/wiki/Tech/News/For_contributors#The_deadlines

There will be more edits by Friday midnight UTC but the existing content
should
generally remain fairly stable. I will let you know on Friday in any
case.

Let us know if you have any questions, comments or concerns. As
always, we appreciate your help and feedback.

(If you haven't translated Tech News previously, see this email:
https://lists.wikimedia.org/pipermail/translators-l/2017-January/003773.html

Thank you!
___
Translators-l mailing list -- translators-l@lists.wikimedia.org
To unsubscribe send an email to translators-l-le...@lists.wikimedia.org

Re: [cabfpub] Draft Charter for IPR Subcommittee

[Clint Wilson via Public]

Hi Ben,

We’re very supportive of chartering this Subcommittee. We’re still reviewing 
and may have some further feedback, but I expect once we’ve completed that we’d 
be able to endorse if needed.

Cheers,
-Clint

> On Apr 18, 2024, at 8:37 AM, Ben Wilson via Public  
> wrote:
> 
> All,
> I will put this in ballot format. I am looking for endorsers.
> Thanks,
> Ben
> 
> On Tue, Apr 16, 2024 at 10:48 AM Ben Wilson  <mailto:bwil...@mozilla.com>> wrote:
>> All,
>> 
>> As mentioned during the Forum teleconference of April 11, 2024, here is a 
>> draft charter for a Forum IPR Subcommittee. (This effort is separate, but 
>> somewhat in parallel to the work of the Patent Advisory Group, which will be 
>> handling GoDaddy's Patent Exclusion Notice, filed Mar. 22, 2024, in relation 
>> to Ballot SC-70.) 
>> 
>> Please provide your comments or questions.
>> 
>> Thanks,
>> 
>> Ben
>> 
>>  
>> 
>> Forum IPR Subcommittee Charter
>> 
>> Upon approval of the CAB Forum by ballot in accordance with section 5.6 of 
>> the Bylaws, the Forum IPR Subcommittee (“FIS”) is created to perform the 
>> activities as specified in this Charter, subject to the terms and conditions 
>> of the CA/Browser Forum Bylaws and Intellectual Property Rights (IPR) 
>> Policy, as such documents may change from time to time. The definitions 
>> found in the Forum’s Bylaws or IPR Policy shall apply to capitalized terms 
>> in this Charter.
>> 
>> Scope
>> 
>> The primary activity of the FIS shall be to review, and propose revisions 
>> to, the Forum’s IPR Policy, IPR Policy Agreement, exclusion notice template, 
>> and similar documents.  The FIS may perform other activities ancillary to 
>> this primary activity.  The FIS will not create Final Guidelines or Final 
>> Maintenance Guidelines.
>> 
>> Anticipated End Date
>> 
>> The FIS is chartered without a specific end date. However, it is expected 
>> that the FIS will deliver results of its initial work to the Forum prior to 
>> _ 2024.  Thereafter, the FIS will continue to exist, but may be 
>> dissolved at any time by Forum ballot.
>> 
>> Initial Chairs and Contacts
>> 
>> The proposer of the ballot adopting this Charter, Ben Wilson, will act as 
>> organizer of the FIS until the first teleconference is held for the FIS, at 
>> which time the FIS will elect a chair and vice-chair, either by vote or by 
>> acclamation of those present. The chair and vice-chair will normally serve 
>> two-year terms.  However, the first term will start upon their election and 
>> run through 31 October 2026.
>> 
>> Members Eligible to Participate
>> 
>> The FIS welcomes the participation of any Member organization of the Forum 
>> interested in this work.  Forum Members that have initially declared their 
>> participation in this Subcommittee are:
>> 
>> Amazon, Apple, DigiCert, GoDaddy, Google, HARICA, Let’s Encrypt, Mozilla, 
>> Sectigo, SwissSign,
>> 
>> Voting and Voting Structure
>> 
>> Voting in the FIS shall be limited to Forum members. Voting shall be 
>> egalitarian: all Members shall vote together as a single class, with one 
>> vote granted to each Member organization. Any decisions of the FIS needed to 
>> be voted upon by the FIS shall be considered adopted if the number of votes 
>> in favor exceeds 50% of the votes cast.
>> 
>> Primary Means of Communication
>> 
>> The FIS will communicate primarily through listserv-based email and shall 
>> conduct periodic calls or face-to-face meetings as needed.
>> 
>> 
>> 
> ___
> Public mailing list
> Public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/public



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

Re: [cabfpub] Draft Charter for IPR Subcommittee

[Ben Wilson via Public]

All,
I will put this in ballot format. I am looking for endorsers.
Thanks,
Ben

On Tue, Apr 16, 2024 at 10:48 AM Ben Wilson  wrote:

> All,
>
> As mentioned during the Forum teleconference of April 11, 2024, here is a
> draft charter for a Forum IPR Subcommittee. (This effort is separate, but
> somewhat in parallel to the work of the Patent Advisory Group, which will
> be handling GoDaddy's Patent Exclusion Notice, filed Mar. 22, 2024, in
> relation to Ballot SC-70.)
>
> Please provide your comments or questions.
>
> Thanks,
>
> Ben
>
>
>
> *Forum IPR Subcommittee Charter*
>
> Upon approval of the CAB Forum by ballot in accordance with section 5.6 of
> the Bylaws, the Forum IPR Subcommittee (“FIS”) is created to perform the
> activities as specified in this Charter, subject to the terms and
> conditions of the CA/Browser Forum Bylaws and Intellectual Property Rights
> (IPR) Policy, as such documents may change from time to time. The
> definitions found in the Forum’s Bylaws or IPR Policy shall apply to
> capitalized terms in this Charter.
>
> *Scope*
>
> The primary activity of the FIS shall be to review, and propose revisions
> to, the Forum’s IPR Policy, IPR Policy Agreement, exclusion notice
> template, and similar documents.  The FIS may perform other activities
> ancillary to this primary activity.  The FIS will not create Final
> Guidelines or Final Maintenance Guidelines.
>
> *Anticipated End Date*
>
> The FIS is chartered without a specific end date. However, it is expected
> that the FIS will deliver results of its initial work to the Forum prior to
> _ 2024.  Thereafter, the FIS will continue to exist, but may be
> dissolved at any time by Forum ballot.
>
> *Initial Chairs and Contacts*
>
> The proposer of the ballot adopting this Charter, Ben Wilson, will act as
> organizer of the FIS until the first teleconference is held for the FIS, at
> which time the FIS will elect a chair and vice-chair, either by vote or by
> acclamation of those present. The chair and vice-chair will normally serve
> two-year terms.  However, the first term will start upon their election
> and run through 31 October 2026.
>
> *Members Eligible to Participate*
>
> The FIS welcomes the participation of any Member organization of the Forum
> interested in this work.  Forum Members that have initially declared
> their participation in this Subcommittee are:
>
> Amazon, Apple, DigiCert, GoDaddy, Google, HARICA, Let’s Encrypt, Mozilla,
> Sectigo, SwissSign,
>
> *Voting and Voting Structure*
>
> Voting in the FIS shall be limited to Forum members. Voting shall be
> egalitarian: all Members shall vote together as a single class, with one
> vote granted to each Member organization. Any decisions of the FIS needed
> to be voted upon by the FIS shall be considered adopted if the number of
> votes in favor exceeds 50% of the votes cast.
>
> *Primary Means of Communication*
>
> The FIS will communicate primarily through listserv-based email and shall
> conduct periodic calls or face-to-face meetings as needed.
>
>
>
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

[RBW] Re: Thumb Shifter Advice

[Aaron Wilson]

Thanks Jim! I'll have to ask around to see if I can try some. Maybe I 
should switch my Microshift 9-speed shifter to friction to test the waters 
in the mean time. 

Glen, I used to use rapid fire, but really like how compact and simple 
thumb shifters are. When my 11-speed commuter ghost shifts, I do miss the 
reliability of a trigger shifter though. 

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/40a5646c-e5aa-41ec-a41b-e40a66cb3f04n%40googlegroups.com.

[cabfpub] Draft Charter for IPR Subcommittee

[Ben Wilson via Public]

All,

As mentioned during the Forum teleconference of April 11, 2024, here is a
draft charter for a Forum IPR Subcommittee. (This effort is separate, but
somewhat in parallel to the work of the Patent Advisory Group, which will
be handling GoDaddy's Patent Exclusion Notice, filed Mar. 22, 2024, in
relation to Ballot SC-70.)

Please provide your comments or questions.

Thanks,

Ben



*Forum IPR Subcommittee Charter*

Upon approval of the CAB Forum by ballot in accordance with section 5.6 of
the Bylaws, the Forum IPR Subcommittee (“FIS”) is created to perform the
activities as specified in this Charter, subject to the terms and
conditions of the CA/Browser Forum Bylaws and Intellectual Property Rights
(IPR) Policy, as such documents may change from time to time. The
definitions found in the Forum’s Bylaws or IPR Policy shall apply to
capitalized terms in this Charter.

*Scope*

The primary activity of the FIS shall be to review, and propose revisions
to, the Forum’s IPR Policy, IPR Policy Agreement, exclusion notice
template, and similar documents.  The FIS may perform other activities
ancillary to this primary activity.  The FIS will not create Final
Guidelines or Final Maintenance Guidelines.

*Anticipated End Date*

The FIS is chartered without a specific end date. However, it is expected
that the FIS will deliver results of its initial work to the Forum prior to
_ 2024.  Thereafter, the FIS will continue to exist, but may be
dissolved at any time by Forum ballot.

*Initial Chairs and Contacts*

The proposer of the ballot adopting this Charter, Ben Wilson, will act as
organizer of the FIS until the first teleconference is held for the FIS, at
which time the FIS will elect a chair and vice-chair, either by vote or by
acclamation of those present. The chair and vice-chair will normally serve
two-year terms.  However, the first term will start upon their election and
run through 31 October 2026.

*Members Eligible to Participate*

The FIS welcomes the participation of any Member organization of the Forum
interested in this work.  Forum Members that have initially declared their
participation in this Subcommittee are:

Amazon, Apple, DigiCert, GoDaddy, Google, HARICA, Let’s Encrypt, Mozilla,
Sectigo, SwissSign,

*Voting and Voting Structure*

Voting in the FIS shall be limited to Forum members. Voting shall be
egalitarian: all Members shall vote together as a single class, with one
vote granted to each Member organization. Any decisions of the FIS needed
to be voted upon by the FIS shall be considered adopted if the number of
votes in favor exceeds 50% of the votes cast.

*Primary Means of Communication*

The FIS will communicate primarily through listserv-based email and shall
conduct periodic calls or face-to-face meetings as needed.
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

[RBW] Thumb Shifter Advice

[Aaron Wilson]

I'll be building up one of the new Susies (in green) soon and I'm *debating 
my thumb-shifter options*. Do you have some advice?

I'll be setting up

   - 9-speed Shimano RD (RD-M952)
   - Triple Shimano FD (FD-M953) on a Silver Wide-low double
   - Inside-mount thumb shifters on Sim Works (Nitto) Ramble bars
   - Preferably, indexed shifting for the rear

I know of

   - *Microshift*. I've got a lot of miles on their 11-speed thumb shifter 
   on my commuter and I get ghost shifts no matter how much I tweak it. I have 
   a lot fewer miles on their 2/3x9 pair on my 90s mountain bike and they 
   haven't given me trouble. 
   - *Paul Thumbie + Shimano SL-BS77*. Tempting, but expensive. Do you have 
   experience with this setup? Can you compare it with Microshift?
   - *Silver2*. Pretty, but not indexed and I'm a scared wimp. Can you 
   convince me friction shifting is the way to go?
   - *Are there other options* (including used or NOS) I should consider?

Thanks in advance, 
Aaron

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/7dbabe56-f275-4213-8c15-20d9d66e8f2en%40googlegroups.com.

Re: testing testing

[mike wilson]

I also seem to be missing a large number of posts.  Also, threads are seriously 
out of sequence.  It's one of the mysteries of (modern) life.
> On 13/04/2024 14:17 BST ann sanfedele  wrote:
> 
>  
> post I made in the last few weeks to PESOS didn't show up in my PDML 
> folder.. and since the end of March I haven't gotten
> -any- PDML list mail at all..  hmmm
>
--
%(real_name)s Pentax-Discuss Mail List
To unsubscribe send an email to pdml-le...@pdml.net
to UNSUBSCRIBE from the PDML, please visit the link directly above and follow 
the directions.

[ovs-dev] [PATCH v2] python: ovsdb-idl: Add custom transaction operations.

[Terry Wilson]

It can be useful to be able to send raw transaction operations
through the Idl's connection. For example, to clean up MAC_Binding
entries for floating IPs without having to monitor the MAC_Binding
table which can be quite large.

Signed-off-by: Terry Wilson 
---
 NEWS |  2 ++
 python/ovs/db/idl.py | 18 ++-
 tests/ovsdb-idl.at   | 27 ++
 tests/test-ovsdb.py  | 55 
 4 files changed, 101 insertions(+), 1 deletion(-)

diff --git a/NEWS b/NEWS
index b92cec532..f30b859fd 100644
--- a/NEWS
+++ b/NEWS
@@ -7,6 +7,8 @@ Post-v3.3.0
- The primary development branch has been renamed from 'master' to 'main'.
  The OVS tree remains hosted on GitHub.
  https://github.com/openvswitch/ovs.git
+   - Python:
+ * Add custom transaction support to the Idl via add_op().
 
 
 v3.3.0 - 16 Feb 2024
diff --git a/python/ovs/db/idl.py b/python/ovs/db/idl.py
index a80da84e7..1220e4cc6 100644
--- a/python/ovs/db/idl.py
+++ b/python/ovs/db/idl.py
@@ -1703,6 +1703,8 @@ class Transaction(object):
 
 self._inserted_rows = {}  # Map from UUID to _InsertedRow
 
+self._operations = []
+
 def add_comment(self, comment):
 """Appends 'comment' to the comments that will be passed to the OVSDB
 server when this transaction is committed.  (The comment will be
@@ -1838,7 +1840,7 @@ class Transaction(object):
"rows": [rows]})
 
 # Add updates.
-any_updates = False
+any_updates = bool(self._operations)
 for row in self._txn_rows.values():
 if row._changes is None:
 if row._table.is_root:
@@ -1977,6 +1979,7 @@ class Transaction(object):
 if self.dry_run:
 operations.append({"op": "abort"})
 
+operations += self._operations
 if not any_updates:
 self._status = Transaction.UNCHANGED
 else:
@@ -1991,6 +1994,19 @@ class Transaction(object):
 self.__disassemble()
 return self._status
 
+def add_op(self, op):
+"""Add a raw OVSDB operation to the transaction
+
+This can be useful for re-using the existing Idl connection to take
+actions that are difficult or expensive to do with the Idl itself. e.g.
+deleting a bunch of rows on the server that you don't want to store
+in memory.
+
+:param op: An "op" for an OVSDB "transact" request (rfc 7047 Sec 5.2)
+:type op:   dict
+"""
+self._operations.append(op)
+
 def commit_block(self):
 """Attempts to commit this transaction, blocking until the commit
 either succeeds or fails.  Returns the final commit status, which may
diff --git a/tests/ovsdb-idl.at b/tests/ovsdb-idl.at
index fb568dd82..487545a13 100644
--- a/tests/ovsdb-idl.at
+++ b/tests/ovsdb-idl.at
@@ -2758,6 +2758,33 @@ OVSDB_CHECK_IDL_PERS_UUID_INSERT([simple idl, persistent 
uuid insert],
   [['This UUID would duplicate a UUID already present within the table or 
deleted within the same transaction']])
 
 
+OVSDB_CHECK_IDL_PY([simple idl, python, add_op],
+  [],
+  [['insert 1, insert 2, insert 3, insert 1' \
+'add_op {"op": "delete", "table": "simple", "where": [["i", "==", 1]]}' \
+'add_op {"op": "insert", "table": "simple", "row": {"i": 2}}, delete 3' \
+'insert 2, add_op {"op": "update", "table": "simple", "row": {"i": 1}, 
"where": [["i", "==", 2]]}'
+  ]],
+  [[000: empty
+001: commit, status=success
+002: table simple: i=1 r=0 b=false s= u=<0> ia=[] ra=[] ba=[] sa=[] ua=[] 
uuid=<1>
+002: table simple: i=1 r=0 b=false s= u=<0> ia=[] ra=[] ba=[] sa=[] ua=[] 
uuid=<2>
+002: table simple: i=2 r=0 b=false s= u=<0> ia=[] ra=[] ba=[] sa=[] ua=[] 
uuid=<3>
+002: table simple: i=3 r=0 b=false s= u=<0> ia=[] ra=[] ba=[] sa=[] ua=[] 
uuid=<4>
+003: commit, status=success
+004: table simple: i=2 r=0 b=false s= u=<0> ia=[] ra=[] ba=[] sa=[] ua=[] 
uuid=<3>
+004: table simple: i=3 r=0 b=false s= u=<0> ia=[] ra=[] ba=[] sa=[] ua=[] 
uuid=<4>
+005: commit, status=success
+006: table simple: i=2 r=0 b=false s= u=<0> ia=[] ra=[] ba=[] sa=[] ua=[] 
uuid=<3>
+006: table simple: i=2 r=0 b=false s= u=<0> ia=[] ra=[] ba=[] sa=[] ua=[] 
uuid=<5>
+007: commit, status=success
+008: table simple: i=1 r=0 b=false s= u=<0> ia=[] ra=[] ba=[] sa=[] ua=[] 
uuid=<3>
+008: table simple: i=1 r=0 b=false s= u=<0> ia=[] ra=[] ba=[] sa=[] ua=[] 
uuid=<5>
+008: table simple: i=1 r=0 b=false s= u=<0> ia=[] ra=[] ba=[] sa=[] ua=

[African Wikimedians] [WLA 2024 Training] Videography Basics for WLA 2024

[Wilson Oluoha]

Dear Friends,

As part of Wiki In Africa's plans to increase participants capacity,
encourage quality contributions and generally improve knowledge and skills
with regards to Wikimedia Commons, we wish to cordially invite *You *to the
sixth WLA training of the year.

*Details* are available on the event page
<https://meta.wikimedia.org/wiki/Event:Videography_Basics_for_WLA_2024>.
Kindly *register* and *share* with interested members of your community.

For information on previous trainings, click here
<https://meta.wikimedia.org/wiki/Category:Wiki_Loves_Africa_Trainings>
For information on news and updates concerning WLA 2024, click here
<https://meta.wikimedia.org/wiki/Wiki_Loves_Africa_2024/News>

Best regards


-- 

*Wilson Oluoha*

UTC+1

Skype: studywilson1106 | Telegram: @Wilsn_Oluoha | Whatsapp: message
<https://wa.me/2348069451106>

Wikimedia  <https://meta.wikimedia.org/wiki/User:OtuNwachinemere>|
<https://www.linkedin.com/in/devouard/>LinkedIn
<https://www.linkedin.com/in/wilson-oluoha-a2b4a6181/> | Website
<https://www.wikilovesafrica.net/> | Instagram
<https://instagram.com/i_see_a_picture> | Twitter
<https://twitter.com/OluohaWilson>

Hear my name <https://namedrop.io/wilsonoluoha>
___
African-Wikimedians mailing list -- african-wikimedians@lists.wikimedia.org
To unsubscribe send an email to african-wikimedians-le...@lists.wikimedia.org

Re: [go-cd] Query re: Gitlab build status notifier

[Chad Wilson]

Hi Steve

I'm not familiar with use of either of these plugins with GitLab, however
it seems pretty clear that the gocd-build-status-notifier plugin does not
have gitlab support merged so the two plugins don't work together right
now. It seemed to be blocked by this comment here

which seems unresolved or not responded to.

The logs (if any) will be in plugin-specific logs rather than the main
server logs.

In any case, if you want to give it a go with v1.4.0-RC4 of the PR Builder
plugin, you can try the test build attached here
.
If it works OK with and without subgroups we can consider merging it. I
have not tested this myself, as I don't have a GitLab setup to test with
(nor time to do so). I'd still be a bit surprised if it works though, as
the Gitlab API interaction hasn't been changed on the notifier for many
years, and I suspect it has evolved

-Chad

On Mon, Apr 8, 2024 at 7:53 PM Steve  wrote:

> Hi,
>
> Got a question for the wonderful, knowledgable people here pls!
>
> I've got a copy of GoCD running in a docker container, GoCD v23.5.0, with
> Gitlab Pull Requests Builder v1.4.0-RC4, Gitlab Merge Requests status
> notifier v1.7.2-276.
>
> While I have got the Gitlab Pull Requests Builder working properly and
> responding to creation/changes in Gitlab Merge Requests with pipeline
> executions on the appropriate branch, I cannot:
>
> 1) get any Gitlab MR status notifications appearing in the MR nor
> 2) see any evidence of the plugin failing or being called at all in the
> GoCD server logs.
>
> Can anyone advise on what I'm doing wrong, if anything, please?
>
> Saw this
> https://github.com/gocd-contrib/gocd-build-status-notifier/pull/134,
> wondering if that's something to do with it (given that the notification
> plugin hasnt been updated in a few years), or maybe
> https://github.com/ashwanthkumar/gocd-build-github-pull-requests/issues/153
> (I'm using an enterprise Gitlab with subgroups that works for the builder
> but maybe it has a problem of some kind working with the notifier?)
>
> Thanks for any light that can be shed on this!
>
> Steve
>
> --
> You received this message because you are subscribed to the Google Groups
> "go-cd" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to go-cd+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/go-cd/a7936d1a-9a65-4d92-979d-36c886b1d150n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"go-cd" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to go-cd+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/go-cd/CAA1RwH-mtcuqweJ_J5aOXdVAOsYCNKDKsoscYNFxWi21KH3%2BcQ%40mail.gmail.com.

Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal

[Clint Wilson via Servercert-wg]

Hi Wayne,

That was indeed my intent, but I’m happy with the proposal either way.

Thank you,
-Clint

> On Apr 12, 2024, at 12:33 PM, Wayne Thayer  wrote:
> 
> Thank you Clint and Aaron, this is helpful. Here is what I propose:
> 
>> In the case of Debian weak keys vulnerability 
>> ([https://wiki.debian.org/SSLkeys)]), the CA SHALL reject all keys found at 
>> [https://github.com/cabforum/debian-weak-keys/] for each key type (e.g. RSA, 
>> ECDSA) and size listed in the repository. For all other key types and sizes, 
>> the CA SHALL reject Debian weak keys.
> 
> This change can be viewed in context 
> https://github.com/wthayer/servercert/pull/1/files
> 
> This language allows us to add key sizes in the future without updating the 
> TLS BRs.
> 
> Clint Wilson: I did not exclude key sizes larger than 8192 RSA/521 ECDSA bits 
> from the requirements but would be happy to do so if you will confirm that 
> this was your intent?
> 
> Rob Stradling: I would like to import your repo to 
> github.com/cabforum/Debian-weak-keys 
> <http://github.com/cabforum/Debian-weak-keys>. May I have your permission to 
> do so?
> 
> Thanks,
> 
> Wayne
> 
> On Thu, Apr 11, 2024 at 10:11 AM Clint Wilson  <mailto:cli...@apple.com>> wrote:
>> Hi Aaron,
>> 
>> Your proposed phrasing sounds good to me and matches what I had in mind as 
>> the end result of the changes represented in Set 1, just structured slightly 
>> differently.
>> 
>> Cheers,
>> -Clint
>> 
>>> On Apr 11, 2024, at 9:47 AM, Aaron Gable >> <mailto:aa...@letsencrypt.org>> wrote:
>>> 
>>> On Thu, Apr 11, 2024 at 9:12 AM Clint Wilson via Servercert-wg 
>>> mailto:servercert-wg@cabforum.org>> wrote:
>>>> In other words, I believe it satisfactory to establish a constrained set 
>>>> of Debian weak keys which CAs must block (rather than leaving the 
>>>> requirement fully open-ended), but I don’t believe that should obviate the 
>>>> need for a CA to check uncommon key sizes — which are otherwise in the key 
>>>> size ranges of that constrained set’s key sizes — should a CA allow those 
>>>> uncommon key sizes. 
>>> 
>>> I completely concur. 
>>> 
>>> I don't think that either of your Set 1 / Set 2 proposals quite hits the 
>>> mark for me, for one reason: they both contain the phrase "CAs must not 
>>> issue certificates containing Debian weak keys". As long as that statement 
>>> exists, the requirement is "evaluate everything yourself, and if new sets 
>>> of weak keys come to light, you're already behind" -- the existence of the 
>>> github repo is just a nicety.
>>> 
>>> Instead, I would phrase the requirement as "In the case of [list of common 
>>> RSA and ECDSA key sizes] Debian Weak Keys, the CA SHALL reject keys 
>>> identified by [link to CABF repository]. For other key sizes, the CA SHALL 
>>> reject Debian Weak Keys."
>>> 
>>> In other words -- for these common key sizes, the repository is the source 
>>> of truth. Every key in it is considered compromised and must be blocked, 
>>> but you don't need to waste time replicating the work of generating all of 
>>> these keys to prove to yourself that it has been done correctly. If you 
>>> want to issue for other key sizes, then the onus is on you to do the 
>>> relevant due diligence.
>>> 
>>> Aaron
>> 



smime.p7s
Description: S/MIME cryptographic signature
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

[Freeipa-users] ipaclient-install.log certutil: Could not find cert:

[C Wilson via FreeIPA-users]

Hello

I'm trying to roll out a new IPA server for our development environment and 
have nicely automated the server installation process with Ansible but when 
I've come to rolling out the clients I'm hitting this problem. 

When running ipa-client-install:
ipa-client-install -N --fixed-primary --server server.domain.local --realm 
DOMAIN.LOCAL --domain DOMAIN.local --principal admin --password 'adminpassword' 
-U

I get the following error:
Please make sure the following ports are opened in the firewall settings:
 TCP: 80, 88, 389
 UDP: 88 (at least one of TCP/UDP ports 88 has to be open)
Also note that following ports are necessary for ipa-client working properly 
after enrollment:
 TCP: 464
 UDP: 464, 123 (if NTP enabled)
Installation failed. Rolling back changes.
Disabling client Kerberos and LDAP configurations
nscd daemon is not installed, skip configuration
nslcd daemon is not installed, skip configuration
Client uninstall complete.
Kerberos authentication failed: kinit: Cannot contact any KDC for realm 
'DOMAIN.LOCAL' while getting initial credentials


I've disabled the firewall on both systems, DNS resolves the server name. I can 
nmap and telnet to the ports listed so I don't think it's a networking issue. 
The ipa server appears to be running fine:

[root@server tmp]# service ipa status
Redirecting to /bin/systemctl status ipa.service
● ipa.service - Identity, Policy, Audit
 Loaded: loaded (/usr/lib/systemd/system/ipa.service; enabled; preset: 
disabled)
 Active: active (exited) since Wed 2024-04-10 15:49:49 UTC; 2 days ago
   Main PID: 18336 (code=exited, status=0/SUCCESS)
CPU: 1.610s

Apr 10 15:49:48 server ipactl[18336]: Assuming stale, cleaning and proceeding
Apr 10 15:49:49 server ipactl[18336]: ipa: INFO: The ipactl command was 
successful
Apr 10 15:49:49 server ipactl[18336]: Starting Directory Service
Apr 10 15:49:49 server ipactl[18336]: Starting krb5kdc Service
Apr 10 15:49:49 server ipactl[18336]: Starting kadmin Service
Apr 10 15:49:49 server ipactl[18336]: Starting httpd Service
Apr 10 15:49:49 server ipactl[18336]: Starting ipa-custodia Service
Apr 10 15:49:49 server ipactl[18336]: Starting pki-tomcatd Service
Apr 10 15:49:49 server ipactl[18336]: Starting ipa-otpd Service
Apr 10 15:49:49 server systemd[1]: Finished Identity, Policy, Audit.


Looking at the ipaclient-install.log there are lines that are semi interesting 
but I can't see how to progress from here to resolve the issue:

2024-04-12T16:25:51Z DEBUG stderr=kinit: Cannot contact any KDC for realm 
'DOMAIN.LOCAL' while getting initial credentials
2024-04-12T16:25:51Z ERROR Installation failed. Rolling back changes.
2024-04-12T16:25:52Z DEBUG stderr=
2024-04-12T16:25:52Z DEBUG stderr=certutil: Could not find cert: IPA Machine 
Certificate - virt01.domain.local
: PR_FILE_NOT_FOUND_ERROR: File not found


but if I run `kinit admin@server.domain.local` it authenticates. 

I seem to be at a dead end, How do I troubleshoot this further? 
--
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

SOLVED: Different results between glp_simplex() and gplsol

[Edscott Wilson]

Problem solved. Stupid mistakes are the hardest to find, at least for me.
A single column had a different bound specification in my call to
glp_simplex().
Different problems, different results. Same problem, same results.

Anyways, glpk is amazing.

Thank you all developers for such fine work!

-- 

Dr. Edscott Wilson Garcia
Reservoir Engineering
Mexican Petroleum Institute

Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal

[Clint Wilson via Servercert-wg]

Hi Aaron,

Your proposed phrasing sounds good to me and matches what I had in mind as the 
end result of the changes represented in Set 1, just structured slightly 
differently.

Cheers,
-Clint

> On Apr 11, 2024, at 9:47 AM, Aaron Gable  wrote:
> 
> On Thu, Apr 11, 2024 at 9:12 AM Clint Wilson via Servercert-wg 
> mailto:servercert-wg@cabforum.org>> wrote:
>> In other words, I believe it satisfactory to establish a constrained set of 
>> Debian weak keys which CAs must block (rather than leaving the requirement 
>> fully open-ended), but I don’t believe that should obviate the need for a CA 
>> to check uncommon key sizes — which are otherwise in the key size ranges of 
>> that constrained set’s key sizes — should a CA allow those uncommon key 
>> sizes. 
> 
> I completely concur. 
> 
> I don't think that either of your Set 1 / Set 2 proposals quite hits the mark 
> for me, for one reason: they both contain the phrase "CAs must not issue 
> certificates containing Debian weak keys". As long as that statement exists, 
> the requirement is "evaluate everything yourself, and if new sets of weak 
> keys come to light, you're already behind" -- the existence of the github 
> repo is just a nicety.
> 
> Instead, I would phrase the requirement as "In the case of [list of common 
> RSA and ECDSA key sizes] Debian Weak Keys, the CA SHALL reject keys 
> identified by [link to CABF repository]. For other key sizes, the CA SHALL 
> reject Debian Weak Keys."
> 
> In other words -- for these common key sizes, the repository is the source of 
> truth. Every key in it is considered compromised and must be blocked, but you 
> don't need to waste time replicating the work of generating all of these keys 
> to prove to yourself that it has been done correctly. If you want to issue 
> for other key sizes, then the onus is on you to do the relevant due diligence.
> 
> Aaron



smime.p7s
Description: S/MIME cryptographic signature
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal

[Clint Wilson via Servercert-wg]

Hi Wayne,

Agreed, your proposal [1] is basically what I was describing; I only added that 
it would be useful, in my mind, to add a repository usable by Certificate 
Issuers (but not required to be used) similar to what we’ve provided for ROCA 
and Close Primes.

However, based on the discussion today, I think both of the below sets of 
changes make sense to me, though I sensed consensus on the call leaning towards 
the first set of changes. Set 2 is intended to be the same as what I previously 
described in Option 2.

I believe the only clarification I’ve added in Set 1, beyond what Aaron and Tim 
discussed, is the addition of a requirement for key sizes other than those 
specifically represented in a known complete (at this time) repository of 
Debian weak keys for common key sizes. At least, that was my only intentional 
addition, so if the described set of changes don’t otherwise align with the 
proposal represented in Aaron and Tim’s discussion, please let me know. 
In other words, I believe it satisfactory to establish a constrained set of 
Debian weak keys which CAs must block (rather than leaving the requirement 
fully open-ended), but I don’t believe that should obviate the need for a CA to 
check uncommon key sizes — which are otherwise in the key size ranges of that 
constrained set’s key sizes — should a CA allow those uncommon key sizes. 

I want to further clarify that I do expect any such repository representing 
this constrained set of Debian weak keys to be updated in the future if some 
meaningful change is identified to Debian weak keys generated in the included 
key size ranges, but this approach would allow that to be a structured process 
within the CA/BF, rather than some “surprise, here’s a random def con preso; 
block all the keys it describes as being possible to generate yesterday please” 
situation as we could otherwise (and currently) encounter.

Set 1:
1) Create a CA/BF repo with presently known Debian weak keys for the key sizes 
RSA 2048, 3072, 4096, 8192; ECC 256, 384, 521 (the repo Rob pointed to seems 
the most complete from what I’ve seen, but no particularly strong opinions here)
2) Update TBRs: For RSA key sizes or smaller than 8193 bits and ECC key sizes 
smaller than 522 bits, CAs must not issue certificates containing Debian weak 
keys
3) Update TBRs: Include a reference to the above CA/BF repo as the set of 
Debian weak keys which meet the requirement of 2) specifically for the key 
sizes RSA 2048, 3072, 4096, 8192; ECC 256, 384, 521 included in that repo
4) Update TBRs: Add an explanatory note clarifying that if a CA allows for 
issuance of certificates other than RSA 2048, 3072, 4096, 8192; ECC 256, 384, 
521, the CA must ensure certificates containing any other key size do not 
contain a Debian weak key

Set 2:
1) Create a CA/BF repo with presently known Debian weak keys for the key sizes 
RSA 2048, 3072, 4096, 8192; ECC 256, 384, 521
2) Update TBRs: For RSA key sizes smaller than 8193 bits and ECC key sizes 
smaller than 522 bits, CAs must not issue certificates containing Debian weak 
keys
3) Update TBRs: Include a reference to the above CA/BF repo as an optional 
resource for CAs to use in checking for Debian weak keys

I hope I’m contributing something useful to this discussion; please reach out 
if I could do better here.

Thank you!
-Clint

[1] https://github.com/wthayer/servercert/pull/1/files

> On Apr 10, 2024, at 11:51 AM, Wayne Thayer  wrote:
> 
> Hi Clint,
> 
> I think my latest proposal [1] is essentially what you are proposing in 
> option #2, the only difference being that we would add repositories 
> containing weak keys to https://cabforum.org/resources/tools/ (and we can do 
> that without a ballot). If you are instead proposing that we require CAs to 
> check for a specified weak keys contained in one or more repositories, then 
> that is similar to Aaron's proposal except that I understand you want to 
> require CAs to also check for weak keys even if they sign non-standard key 
> sizes that are not included in the repository of weak keys.
> 
> The more I think about the two approaches, the more I prefer my current 
> proposal [1] that does not require CAs to check for specific keys found in 
> one or more repositories. The reason is that I believe CAs already have 
> Debian weak key checks in place and would likely prefer not to have to change 
> their systems to use different logic/data to meet the same requirement as 
> before.
> 
> Thanks,
> 
> Wayne
> 
> [1] https://github.com/wthayer/servercert/pull/1/files
> 
> 
> 
> On Tue, Apr 9, 2024 at 2:26 PM Clint Wilson  <mailto:cli...@apple.com>> wrote:
>> Hi Wayne,
>> 
>> I think this does seem like it could be a tractable solution, however I’d 
>> like to understand why one of the proposals I’ve brought up a couple times 
>> on the calls isn’t also a suitable optio

Re: [go-cd] Help Needed with GoCD Docker Setup and cruise-config.xml Configuration

[Chad Wilson]

[Thread-79]
>> DefaultPluginJarChangeListener:74 - Plugin load finished:
>> /go-working-dir/plugins/bundled/gocd-filebased-authentication-plugin.jar
>> 2024-04-11 08:10:59,359 INFO  [Thread-79]
>> DefaultPluginJarChangeListener:67 - Plugin load starting:
>> /go-working-dir/plugins/bundled/gocd-yaml-config-plugin.jar
>> 2024-04-11 08:11:01,493 INFO  [Thread-79] ConfigRepositoryInitializer:108
>> - [Config Repository Initializer] Start initializing the config
>> repositories for plugin 'yaml.config.plugin'
>> 2024-04-11 08:11:01,499 INFO  [Thread-79] ConfigRepositoryInitializer:112
>> - [Config Repository Initializer] Done initializing the config repositories
>> for plugin 'yaml.config.plugin'
>> 2024-04-11 08:11:01,538 INFO  [Thread-79]
>> DefaultPluginJarChangeListener:74 - Plugin load finished:
>> /go-working-dir/plugins/bundled/gocd-yaml-config-plugin.jar
>> 2024-04-11 08:11:01,579 INFO  [Thread-79]
>> DefaultPluginJarChangeListener:67 - Plugin load starting:
>> /go-working-dir/plugins/external/gocd-slack-notifier-1.4.0.jar
>> 2024-04-11 08:11:01,710 ERROR [Thread-79] PluginLoader:121 - Failed to
>> load plugin: plugins_work/gocd-slack-notifier-1.4.0.jar. Plugin is invalid.
>> Reasons [Class [GoNotificationPlugin] is annotated with @Extension but
>> cannot be constructed. Reason: java.lang.RuntimeException: Unable to find
>> go_notify.conf. Please make sure you've set it up right.., No extensions
>> found in this plugin. Please check for @Extension annotations]
>> 2024-04-11 08:11:01,723 INFO  [Thread-79]
>> DefaultPluginJarChangeListener:74 - Plugin load finished:
>> /go-working-dir/plugins/external/gocd-slack-notifier-1.4.0.jar
>> 2024-04-11 08:11:01,763 INFO  [Thread-79]
>> DefaultPluginJarChangeListener:67 - Plugin load starting:
>> /go-working-dir/plugins/external/gocd-ec2-elastic-agent-plugin-2.2.2.jar
>> 2024-04-11 08:11:02,693 INFO  [Thread-79] GoConfigDao:108 - Config update
>> request by anonymous is in queue -
>> com.thoughtworks.go.config.update.ReplaceElasticAgentInformationCommand@424dd8d0
>> 2024-04-11 08:11:02,705 INFO  [Thread-79] GoConfigDao:111 - Config update
>> request
>> com.thoughtworks.go.config.update.ReplaceElasticAgentInformationCommand@424dd8d0
>> by anonymous is being processed
>> 2024-04-11 08:11:02,832 INFO  [Thread-79] MagicalGoConfigXmlWriter:85 -
>> [Serializing Config] Generating config partial.
>> 2024-04-11 08:11:02,908 INFO  [Thread-79] GoFileConfigDataSource:587 -
>> [Configuration Changed] Saving updated configuration.
>> 2024-04-11 08:11:02,936 INFO  [Thread-79] CachedGoConfig:223 - About to
>> notify config listeners
>> 2024-04-11 08:11:02,941 INFO  [Thread-79] BuildAssignmentService:250 -
>> [Configuration Changed] Removing jobs for pipelines that no longer exist in
>> configuration.
>> 2024-04-11 08:11:02,944 INFO  [Thread-79] CachedGoConfig:231 - Finished
>> notifying all listeners
>> 2024-04-11 08:11:02,945 INFO  [Thread-79] GoConfigDao:126 - Config update
>> request by anonymous is completed
>> 2024-04-11 08:11:02,985 WARN  [Thread-79] PluginSettingsMetadataLoader:63
>> - Failed to fetch plugin settings metadata for plugin
>> com.continuumsecurity.elasticagent.ec2. Maybe the plugin does not implement
>> plugin settings and view?
>> 2024-04-11 08:11:02,986 WARN  [Thread-79] PluginSettingsMetadataLoader:64
>> - Plugin: com.continuumsecurity.elasticagent.ec2 - Metadata load info:
>> [{extension='elastic-agent', configuration='null', view='null',
>> error='java.lang.NullPointerException: Cannot invoke
>> "com.continuumsecurity.elasticagent.ec2.Request.ordinal()" because the
>> return value of
>> "com.continuumsecurity.elasticagent.ec2.Request.fromString(String)" is
>> null'}]
>> 2024-04-11 08:11:02,986 WARN  [Thread-79] PluginSettingsMetadataLoader:65
>> - Not all plugins are required to implement the request above. This error
>> may be safe to ignore.
>> 2024-04-11 08:11:03,022 INFO  [Thread-79]
>> DefaultPluginJarChangeListener:74 - Plugin load finished:
>> /go-working-dir/plugins/external/gocd-ec2-elastic-agent-plugin-2.2.2.jar
>> 2024-04-11 08:11:03,057 INFO  [Thread-79]
>> DefaultPluginJarChangeListener:67 - Plugin load starting:
>> /go-working-dir/plugins/external/gocd-groovy-dsl-config-plugin-2.0.0-241.jar
>> 2024-04-11 08:11:03,972 INFO  [Thread-79] ConfigRepositoryInitializer:108
>> - [Config Repository Initializer] Start initializing the config
>> repositories for plugin 'cd.go.contrib.plugins.configrepo.groovy'
>> 2024-04-11 08:11:03,977 INFO  [Thread-79] ConfigRepositoryInitializer:112
>&g

Different results between glp_simplex() and gplsol

[Edscott Wilson]

Hello,

If I construct a matrix for a problem to feed glp_simplex() and run,
[code]
  glp_smcp parm;
  glp_init_smcp();
  int retval = glp_simplex(lp, );
  double *x = calloc(vectorSize(data)+1, sizeof(double));
  double z = glp_get_obj_val(lp);
  fprintf(stdout, "\nZ=%lf\n", z);
[/code]
I get the following:

GLPK Simplex Optimizer 5.0
15 rows, 17 columns, 33 non-zeros
  0: obj =   0.0e+00 inf =   1.168e+03 (4)
 13: obj =   2.72000e+01 inf =   1.743e+02 (1)
LP HAS NO PRIMAL FEASIBLE SOLUTION
Z=27.20

But if I use the same matrix information to generate a CPLEX format file
and run $ glpsol --lp  cplex.lp -o out, I get:

GLPSOL--GLPK LP/MIP Solver 5.0
Reading problem data from 'cplex.lp'...
15 rows, 17 columns, 33 non-zeros
36 lines were read
GLPK Simplex Optimizer 5.0
15 rows, 17 columns, 33 non-zeros
Preprocessing...
1 row, 2 columns, 2 non-zeros
Scaling...
 A: min|aij| =  1.000e+00  max|aij| =  8.218e+02  ratio =  8.218e+02
GM: min|aij| =  1.000e+00  max|aij| =  1.000e+00  ratio =  1.000e+00
EQ: min|aij| =  1.000e+00  max|aij| =  1.000e+00  ratio =  1.000e+00
Constructing initial basis...
Size of triangular part is 1
* 0: obj =   1.71400e+02 inf =   0.000e+00 (1)
* 1: obj =   2.72000e+01 inf =   0.000e+00 (0)
OPTIMAL LP SOLUTION FOUND
Time used:   0.0 secs
Memory used: 0.0 Mb (40400 bytes)
Writing basic solution to 'out'...

And the optimal solution is Z=27.2

I suppose I am missing something in the call to glp_simplex(), but what?

This is the CPLEX format:

MINIMIZE Z :  + x11 + x12 + x13 + x14
SUBJECT TO
  r1 : + 821.80 x1 + 821.80 x2 + 821.80 x9 = 821.80
  r2 : + 174.30 x3 + 174.30 x4 + 174.30 x10 = 174.30
  r3 : + 27.20 x5 + 27.20 x6 = 27.20
  r4 : + 144.20 x7 + 144.20 x8 = 144.20
  r5 : + 821.80 x1 + 174.30 x3 - 27.20 x5 - 144.20 x7 +
1.00 x11 + 1.00 x13 - 1.00 x16 = 0.00
  r6 : + 821.80 x2 + 174.30 x4 - 27.20 x6 - 144.20 x8 +
1.00 x12 + 1.00 x14 - 1.00 x17 = 0.00
  r7 : - 28.00 x3 >= 0.00
  r8 : - 40.00 x4 >= 0.00
  r9 : - 7.20 x7 >= 0.00
  r10 : - 34.70 x11 >= 0.00
  r11 : - 46.70 x12 >= 0.00
  r12 : - 0.165000 x1 >= 0.00
  r13 : - 0.232000 x3 >= 0.00
  r14 : - 0.067000 x4 >= 0.00
  r15 : - 0.016000 x6 >= 0.00
BOUNDS
 0 <= x1 <= 1
 0 <= x2 <= 1
 0 <= x3 <= 1
 0 <= x4 <= 1
 0 <= x5 <= 1
 0 <= x6 <= 1
 0 <= x7 <= 1
 0 <= x8 <= 1
 0 <= x9 <= 1
 0 <= x10 <= 1
 0 <= x11
 0 <= x12
 0 <= x13
 0 <= x14
 0 <= x15
 0 <= x16
 0 <= x17
END

And this is the matrix information from which the CPLEX format is
constructed:
\* GLPK matrix:
\* ia[1]=1, ja[1]=1, ra[1]=821.80
\* ia[2]=1, ja[2]=2, ra[2]=821.80
\* ia[3]=1, ja[3]=9, ra[3]=821.80
\* ia[4]=2, ja[4]=3, ra[4]=174.30
\* ia[5]=2, ja[5]=4, ra[5]=174.30
\* ia[6]=2, ja[6]=10, ra[6]=174.30
\* ia[7]=3, ja[7]=5, ra[7]=27.20
\* ia[8]=3, ja[8]=6, ra[8]=27.20
\* ia[9]=4, ja[9]=7, ra[9]=144.20
\* ia[10]=4, ja[10]=8, ra[10]=144.20
\* ia[11]=5, ja[11]=15, ra[11]=0.00
\* ia[12]=5, ja[12]=1, ra[12]=821.80
\* ia[13]=5, ja[13]=3, ra[13]=174.30
\* ia[14]=5, ja[14]=11, ra[14]=1.00
\* ia[15]=5, ja[15]=13, ra[15]=1.00
\* ia[16]=5, ja[16]=5, ra[16]=-27.20
\* ia[17]=5, ja[17]=7, ra[17]=-144.20
\* ia[18]=5, ja[18]=16, ra[18]=-1.00
\* ia[19]=6, ja[19]=2, ra[19]=821.80
\* ia[20]=6, ja[20]=4, ra[20]=174.30
\* ia[21]=6, ja[21]=12, ra[21]=1.00
\* ia[22]=6, ja[22]=14, ra[22]=1.00
\* ia[23]=6, ja[23]=6, ra[23]=-27.20
\* ia[24]=6, ja[24]=8, ra[24]=-144.20
\* ia[25]=6, ja[25]=17, ra[25]=-1.00
\* ia[26]=7, ja[26]=3, ra[26]=-28.00
\* ia[27]=8, ja[27]=4, ra[27]=-40.00
\* ia[28]=9, ja[28]=7, ra[28]=-7.20
\* ia[29]=10, ja[29]=11, ra[29]=-34.70
\* ia[30]=11, ja[30]=12, ra[30]=-46.70
\* ia[31]=12, ja[31]=1, ra[31]=-0.165000
\* ia[32]=13, ja[32]=3, ra[32]=-0.232000
\* ia[33]=14, ja[33]=4, ra[33]=-0.067000
\* ia[34]=15, ja[34]=6, ra[34]=-0.016000

What am I missing in the glp_simplex call?  Or maybe I should just stick
with creating the cplex format and do an execlp()?

Any clues are warmly appreciated.




-- 

Dr. Edscott Wilson Garcia
Reservoir Engineering
Mexican Petroleum Institute

Re: [Smcwg-public] Ballot SMC06v2: Post implementation clarification and corrections

[Clint Wilson via Smcwg-public]

Apple votes YES on Ballot SMC06v2.

> On Apr 4, 2024, at 11:15 AM, Stephen Davidson via Smcwg-public 
>  wrote:
> 
> Ballot SMC06: Post implementation clarification and corrections
>  
> Purpose of Ballot:
>  
> The ballot proposes changes to the S/MIME Baseline Requirements to provide 
> clarifications and corrections arising from the implementation of the S/MIME 
> BR and initial audits.
>  
> The following motion has been proposed by Stephen Davidson of DigiCert and 
> endorsed by Martijn Katerbarg of Sectigo and Roman Fischer of SwissSign.
>  
> — MOTION BEGINS —
>  
> This ballot modifies the “Baseline Requirements for the Issuance and 
> Management of Publicly-Trusted S/MIME Certificates” (“S/MIME Baseline 
> Requirements”) resulting in Version 1.0.4.
>  
> The proposed modifications to the S/MIME Baseline Requirements may be found 
> athttps://github.com/srdavidson/smime/compare/ed36440d7c967732aa08739b14cc29bed257a67d...246fab8b8880aa62cec95b6d055b872173d4dadf
>  
> 
>  
> The SMCWG Chair or Vice-Chair is permitted to update the Relevant Dates and 
> Version Number of the S/MIME Baseline Requirements to reflect final dates.
>  
> — MOTION ENDS —
>  
> This ballot proposes a Final Maintenance Guideline. The procedure for 
> approval of this ballot is as follows:
>  
> Discussion (9 days)
> Start Time: Tuesday March 26, 2024 17:00 UTC
> End Time: Thursday April 4, 2024 17:00 UTC
>  
> Vote for approval (7 days)
> Start Time: Thursday April 4, 2024 17:00 UTC 
> End Time: Thursday April 11, 2024 17:00 UTC
>  
> IPR Review (30 days)
>  
> ___
> Smcwg-public mailing list
> Smcwg-public@cabforum.org 
> https://lists.cabforum.org/mailman/listinfo/smcwg-public



smime.p7s
Description: S/MIME cryptographic signature
___
Smcwg-public mailing list
Smcwg-public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/smcwg-public

Re: [ovs-dev] [PATCH 2/3] python: ovsdb-idl: Make IndexedRows mirror hmap.

[Terry Wilson]

I tried to get this to thread under the "ovsdb-idl: potential issues
with the persistent UUID implementation" thread, but failed. This is
one potential solution to that which mirrors the current C IDL
implementation which seems to work for the most part, but relying on
the fact that hmaps allow duplicate keys wasn't necessarily intended
there. Reading that thread is definitely a prerequisite for
understanding why this patch exists. And it may be better to solve
this some other way, but it seems difficult to do for the case of
"inserting a UUID that already exists" w/o creating a race condition
with multiple IDL clients.

Terry

On Wed, Apr 10, 2024 at 4:39 PM Terry Wilson  wrote:
>
> The Python IDL code very closely mirrors the C IDL code, which uses
> an hmap to store table rows. hmap code allows duplicate keys, while
> IndexedRows, which is derived from DictBase does not.
>
> The persistent UUID code can attempt to temporarily add a Row with
> a duplicate UUID to table.rows, so IndexedRows is modified to
> behave similarly to the C IDL's hmap implementation.
>
> Fixes: 55b9507e6824 ("ovsdb-idl: Add the support to specify the uuid for row 
> insert.")
> Signed-off-by: Terry Wilson 
> ---
>  python/ovs/db/custom_index.py | 13 ++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/python/ovs/db/custom_index.py b/python/ovs/db/custom_index.py
> index 587caf5e3..3fa03d3c9 100644
> --- a/python/ovs/db/custom_index.py
> +++ b/python/ovs/db/custom_index.py
> @@ -90,14 +90,21 @@ class IndexedRows(DictBase, object):
>  index = self.indexes[name] = MultiColumnIndex(name)
>  return index
>
> +def __getitem__(self, key):
> +return self.data[key][-1]
> +
>  def __setitem__(self, key, item):
> -self.data[key] = item
> +try:
> +self.data[key].append(item)
> +except KeyError:
> +self.data[key] = [item]
>  for index in self.indexes.values():
>  index.add(item)
>
>  def __delitem__(self, key):
> -val = self.data[key]
> -del self.data[key]
> +val = self.data[key].pop()
> +if len(self.data[key]) == 0:
> +del self.data[key]
>  for index in self.indexes.values():
>  index.remove(val)
>
> --
> 2.34.3
>

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [go-cd] Help Needed with GoCD Docker Setup and cruise-config.xml Configuration

[Chad Wilson]

Hi Satya

When running a standard GoCD docker server image, you should mount a
writable volume to the entire */godata* directory which includes the config
as noted at https://hub.docker.com/r/gocd/gocd-server, but not directly to
an individual config file.

If you do not, even if you get the config working properly, you'll lose
other things such as artifacts at startup which you generally do not want.

You are getting this error likely because the server ID inside the go
config does not match what is inside the configuration history, which is
normally at /godata/db/config.git (The GoCD Docker entrypoint script
creates the symlinks into /go-working-dir within the docker-entrypoint.sh
),
so these things need to be mounted together and consistent.

I don't think your mounts to /var/lib/go-server or /etc/go will be doing
anything, as these folders are not used for *off-the-shelf* docker server
images, since the server is not installed as an rpm/deb package when
creating a container. You can/should likely remove these.

In a general sense, all you should need to do is mount a location in EFS to
/godata, similar to what the Helm chart does:
https://github.com/gocd/helm-chart/blob/c734ad2263b1d2885229d00267c428e88f868504/gocd/templates/gocd-server-deployment.yaml#L122-L124
That will put all logs, artifacts, databases and config on your volume.
Some folks decide to also mount /home/go if they want to use external
storage for things like Git SSH keys or other shell defaults affecting the
*go* user, but that's optional.

-Chad

On Thu, Apr 11, 2024 at 5:34 AM Satya Elipe  wrote:

>
> Dear GoCD Support Team,
>
>
> I hope this message finds you well. I am currently encountering an issue
> with setting up GoCD on Docker and specifically with configuring the
> cruise-config.xml file to be recognized correctly in my setup. Despite
> following the official documentation and trying various configurations,
> I've hit a stumbling block that I hope you can help me with.
>
>
> *Issue Summary:*
>
> I have a GoCD server running in a Docker container, and I'm attempting to
> ensure that the cruise-config.xml file is correctly picked up from a
> specified location. My goal is to mount this configuration file from an
> external volume into the GoCD server container so that the server uses this
> configuration instead of the default one.
>
> *Configuration Details:*
>
>- *GoCD Server Image Version:* gocd/gocd-server:v22.3.0
>- *Docker Version:* Docker version 25.0.3, build 4debf41
>- *Host Operating System:* Amazon Linux 2023
>
> *Docker Run Command:*
>
> docker run -d \
>
>   --name gocd-server \
>
>   -p 8153:8153 \
>
>   -p 8154:8154 \
>
>   -v /mnt/gocd_efs:/var/lib/go-server \
>
>   -v
> /mnt/gocd_efs/etc_go/cruise-config.xml:/go-working-dir/config/cruise-config.xml
> \
>
>   -v /mnt/gocd_efs/etc_go:/etc/go \
>
>   custom-gocd-server
>
>
>
> *Issue Encountered:*
>
> When including the -v
> /mnt/gocd_efs/etc_go/cruise-config.xml:/go-working-dir/config/cruise-config.xml
> volume mount, the GoCD server fails to start correctly, with logs
> indicating an inability to create or copy necessary files within
> /go-working-dir/config.
>
>
> Without this mount, the server starts but does not load the desired
> configuration, defaulting instead to the initial configuration without any
> of our pipeline configurations.
>
>
> Log snippet:
> ```
> jvm 1| 2024-04-10 20:55:17,429 ERROR [Thread-79]
> GoFileConfigDataSource:436 - Unable to load config file:
> /go-working-dir/config/cruise-config.xml The value of 'serverId' uniquely
> identifies a Go server instance. This field cannot be modified.
>
> ```
>
>
>
> *Questions:*
>
>- Is there a recommended approach to ensure cruise-config.xml is
>correctly recognized and used by the GoCD server when running in Docker?
>- Could this issue be related to how volumes are mounted or
>permissions within the container?
>
>
> Any assistance or insights you could provide on this matter would be
> greatly appreciated. I am happy to provide any further information or logs
> as needed.
>
> Thank you for your time and support.
>
>
>
> Best regards,
>
> Satya
>
> --
> You received this message because you are subscribed to the Google Groups
> "go-cd" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to go-cd+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/go-cd/CADKEDRrF7KRFP9jNsg631STyokXS1Njqutdshd0ZKdwHMRTy6g%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"go-cd" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to go-cd+unsubscr...@googlegroups.com.
To view this 

[ovs-dev] [PATCH 3/3] python: ovsdb-idl: Convert new_uuid insert() arg to UUID.

[Terry Wilson]

The argument to insert() should be a uuid.UUID object. If it isn't
then a Row is created with a string uuid attribute and that row is
added to table.rows with a string key instead of a UUID key.

Fixes: 55b9507e6824 ("ovsdb-idl: Add the support to specify the uuid for row 
insert.")
Signed-off-by: Terry Wilson 
---
 python/ovs/db/idl.py | 2 +-
 tests/test-ovsdb.py  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/python/ovs/db/idl.py b/python/ovs/db/idl.py
index a80da84e7..0e201366b 100644
--- a/python/ovs/db/idl.py
+++ b/python/ovs/db/idl.py
@@ -1854,7 +1854,7 @@ class Transaction(object):
 if row._data is None:
 op["op"] = "insert"
 if row._persist_uuid:
-op["uuid"] = row.uuid
+op["uuid"] = str(row.uuid)
 else:
 op["uuid-name"] = _uuid_name_from_uuid(row.uuid)
 
diff --git a/tests/test-ovsdb.py b/tests/test-ovsdb.py
index 48f8ee2d7..6307aa2bd 100644
--- a/tests/test-ovsdb.py
+++ b/tests/test-ovsdb.py
@@ -434,7 +434,7 @@ def idl_set(idl, commands, step):
 sys.stderr.write('"set" command requires 2 argument\n')
 sys.exit(1)
 
-s = txn.insert(idl.tables["simple"], new_uuid=args[0],
+s = txn.insert(idl.tables["simple"], new_uuid=uuid.UUID(args[0]),
persist_uuid=True)
 s.i = int(args[1])
 elif name == "delete":
-- 
2.34.3

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH 2/3] python: ovsdb-idl: Make IndexedRows mirror hmap.

[Terry Wilson]

The Python IDL code very closely mirrors the C IDL code, which uses
an hmap to store table rows. hmap code allows duplicate keys, while
IndexedRows, which is derived from DictBase does not.

The persistent UUID code can attempt to temporarily add a Row with
a duplicate UUID to table.rows, so IndexedRows is modified to
behave similarly to the C IDL's hmap implementation.

Fixes: 55b9507e6824 ("ovsdb-idl: Add the support to specify the uuid for row 
insert.")
Signed-off-by: Terry Wilson 
---
 python/ovs/db/custom_index.py | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/python/ovs/db/custom_index.py b/python/ovs/db/custom_index.py
index 587caf5e3..3fa03d3c9 100644
--- a/python/ovs/db/custom_index.py
+++ b/python/ovs/db/custom_index.py
@@ -90,14 +90,21 @@ class IndexedRows(DictBase, object):
 index = self.indexes[name] = MultiColumnIndex(name)
 return index
 
+def __getitem__(self, key):
+return self.data[key][-1]
+
 def __setitem__(self, key, item):
-self.data[key] = item
+try:
+self.data[key].append(item)
+except KeyError:
+self.data[key] = [item]
 for index in self.indexes.values():
 index.add(item)
 
 def __delitem__(self, key):
-val = self.data[key]
-del self.data[key]
+val = self.data[key].pop()
+if len(self.data[key]) == 0:
+del self.data[key]
 for index in self.indexes.values():
 index.remove(val)
 
-- 
2.34.3

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH 1/3] ovsdb-idl: Add python keyword to persistent UUID test.

[Terry Wilson]

The Python persistent UUID tests should have the keyword "python"
added so that TESTSUITEFLAGS="-k python" will not miss testing
them.

Fixes: 55b9507e6824 ("ovsdb-idl: Add the support to specify the uuid for row 
insert.")
Signed-off-by: Terry Wilson 
---
 tests/ovsdb-idl.at | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/ovsdb-idl.at b/tests/ovsdb-idl.at
index fb568dd82..c9e36d678 100644
--- a/tests/ovsdb-idl.at
+++ b/tests/ovsdb-idl.at
@@ -2713,7 +2713,7 @@ m4_define([OVSDB_CHECK_IDL_PERS_UUID_INSERT_C],
 
 m4_define([OVSDB_CHECK_IDL_PERS_UUID_INSERT_PY],
   [AT_SETUP([$1 - Python3])
-   AT_KEYWORDS([idl persistent uuid insert])
+   AT_KEYWORDS([idl python persistent uuid insert])
OVSDB_START_IDLTEST([], ["$abs_srcdir/idltest.ovsschema"])
AT_CHECK([$PYTHON3 $srcdir/test-ovsdb.py  -t10 idl 
$srcdir/idltest.ovsschema unix:socket $2],
 [0], [stdout], [stderr])
-- 
2.34.3

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [cabfpub] Patent Advisory Group Formation

[Ben Wilson via Public]

Just a reminder -
If you or your IP counsel are interested in participating in the Patent
Advisory Group, please let me know by close of business Friday.
Thanks.  Ben

On Thu, Mar 28, 2024 at 11:03 AM Ben Wilson via Public 
wrote:

> All,
> In today's Forum call, I announced that we are collecting the names and
> email addresses of participants in the Patent Advisory Group through
> Friday, April 12, 2024, and then we'll get started.
> Thanks,
> Ben
> ___
> Public mailing list
> Public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/public
>
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal

[Clint Wilson via Servercert-wg]

fer or 
> object to either of these alternatives?
> 
> Thanks,
> 
> Wayne
> 
> On Thu, Mar 28, 2024 at 4:13 PM Wayne Thayer via Servercert-wg 
> mailto:servercert-wg@cabforum.org>> wrote:
> There was further discussion of this ballot proposal on today's 
> teleconference. It was suggested that rather than omitting any reference to 
> Debian weak keys, the ballot should retain the current language. 
> Unfortunately, the ballot restructures the language in such a way that this 
> is challenging. My new proposal is that TLS BR Section 6.1.1.3(5) be updated 
> to read as follows (https://github.com/wthayer/servercert/pull/1/files):
> =
> 5. The Public Key corresponds to an industry-demonstrated weak Private Key. 
> For requests submitted on or after November 15, 2024, at least the following 
> precautions SHALL be implemented:
> 1. The CA SHALL reject Debian weak keys (https://wiki.debian.org/SSLkeys).
> 2. In the case of ROCA vulnerability, the CA SHALL reject keys identified 
> by the tools available at https://github.com/crocs-muni/roca or equivalent.
> 3. In the case of Close Primes vulnerability 
> (https://fermatattack.secvuln.info/), the CA SHALL reject weak keys which can 
> be factored within 100 rounds using Fermat’s factorization method.  
> 
> Suggested tools for checking for weak keys can be found here: 
> https://cabforum.org/resources/tools/
> =
> I would greatly appreciate feedback from any member that finds this language 
> unacceptable, or that has suggestions to improve it.
> 
> Thanks,
> 
> Wayne
> 
> 
> On Fri, Mar 15, 2024 at 11:19 AM Wayne Thayer via Servercert-wg 
> mailto:servercert-wg@cabforum.org>> wrote:
> On yesterday's SCWG teleconference, Mads suggested that a way forward would 
> be to leave the existing requirements in place for Debian weak keys. I've 
> interpreted that to mean that we would just remove references to Debian, 
> resulting in this: https://github.com/wthayer/servercert/pull/1/files
> 
> I'm not satisfied by this approach because it doesn't achieve the clarity 
> intended to result from the original weak keys ballot and will seemingly 
> result in CAs continuing to have varying interpretations of the specific 
> requirements for rejecting Debian weak keys, but perhaps this is the best we 
> can all agree to.
> 
> What  do others think? Should we proceed with this approach?
> 
> Thanks,
> 
> Wayne
> 
> On Sat, Mar 9, 2024 at 9:15 AM Dimitris Zacharopoulos (HARICA) via 
> Servercert-wg  <mailto:servercert-wg@cabforum.org>> wrote:
> FWIW, I think in the recent years, it was mostly security researchers that 
> attempted to request certificates with Debian weak keys to test if a CA was 
> properly blocking them.
> 
> If an Applicant uses an outdated OS that generates weak keys, imagine the 
> actual web server or other software that runs on that server, putting Relying 
> Parties at risk. CAs don't have control over that but they could have control 
> over a common set of weak keys using common parameters/algorithms which could 
> be enforced by all CAs.
> 
> Dimitris.
> 
> On 9/3/2024 12:05 π.μ., Wayne Thayer via Servercert-wg wrote:
> Hi Clint,
> 
> Thank you for your response. Unfortunately, it leads me to the conclusion 
> that there is not a path forward and we're stuck with the status quo. Having 
> said that, I'll reply to a few of your points below and encourage others to 
> do the same if there is a desire to move forward with an update to our weak 
> keys requirements.
> 
> On Thu, Mar 7, 2024 at 12:59 AM Clint Wilson  <mailto:cli...@apple.com>> wrote:
> Hi Wayne,
> 
> Thank you for carrying this work item forward. I have a few concerns 
> regarding the proposed removal of Debian weak key checking, outlined below.
> 
> I don’t believe there has been sufficient explanation or data presented to 
> justify the removal of the requirement to check for Debian weak keys. It 
> seems to me there are feasible methods for CAs to continue performing this 
> check. Similar to what Martijn has pointed out, the reasoning provided is 
> lacking (hasty generalization, fallacy of composition, etc.).
> 
> The argument that I find compelling is that any system capable of generating 
> a Debian weak key in 2024 is also riddled with a decade of vulnerabilities, 
> so preventing the use of said weak key in a certificate is security theater. 
> In what scenario do you envision the rejection of a Debian weak key having a 
> meaningful impact on the security of a service that relies on it? It's just 
> not obvious to me that these checks continue to provide any practical value 
> at this point in time.
>  
> I don’t believe a compromise where 

[cabf_netsec] Discussion Period Begins | Ballot NS-003: Restructure the NCSSRs

[Clint Wilson via Netsec]

Ballot NS-003 is proposed by Clint Wilson of Apple and endorsed by Trevoli 
Ponds-White of Amazon and David Kluge of Google Trust Services.

Please note, this ballot has set a 2 week Discussion Period.

Purpose of Ballot

This ballot proposes a comprehensive restructuring of the Network and 
Certificate System Security Requirements (NCSSRs), excepting Section 4. The 
current structure of the document has proven to be challenging for creating 
ballots, contains duplicated requirements, and separates similar requirements 
across the document. These issues have led to inefficiencies in managing and 
implementing security standards. Therefore, this proposal aims to streamline 
the document's structure, eliminate redundancies, improve comprehensibility, 
and enhance clarity and coherence.

Reasons for Proposal:

Complexity in Ballot Creation: The current document structure can make it 
difficult to create and manage ballots efficiently, leading to somewhat awkward 
updating processes, abandoned ballots, and a lack of confidence that ballots 
effect the intended changes.
Redundancy: Over time, some parts of the NCSSRs have touched on the same topic, 
leading to some duplication across the document and further to confusion and 
inconsistency in implementation.
Fragmentation: Similar requirements for different parts of a CA’s 
NCSSR-relevant infrastructure are scattered throughout the document, making it 
somewhat more difficult for to locate and comprehend a complete picture of 
these requirements effectively.
Minor Issues: The document contains other, more minor issues that also impede 
its usability and effectiveness, such as missing definitions, unclear list 
structures, and requirements that are more optional than they may currently 
appear.

Benefits of the Updated Document Structure:

Enhanced Clarity: The revised structure should improve the clarity and 
coherence of the document, making the requirements it represents easier to 
understand, as well as result in greater consistency when implementing or 
assessing its security requirements.
Future Updates: A more granular document structure should improve the process 
of creating and managing ballots in the future. Similarly, the improved 
proximity of related requirements should hopefully aid in identifying the areas 
the NCSSRs can most benefit from further attention.
Grouping and De-duplication of Similar Requirements: By consolidating 
duplicated requirements, the updated document should make it much easier to 
find, comprehend, assess, and implement related requirements.
Clearer Recommendations: The updated document includes a number of additional 
“SHOULD”-type stipulations, clarifying some of the language in the current 
NCSSRs such that it’s easier to identify where the NCSSRs impose a strict 
requirement as opposed to a strong recommendation.

Overall, this ballot proposal seeks to address existing challenges in updating 
the current version of the NCSSRs and pave the way for future improvements to 
the NCSSRs.

MOTION BEGINS

This ballot modifies the “Network and Certificate System Security Requirements” 
as follows, based on version 1.7:

https://github.com/cabforum/netsec/compare/c62a2f88e252de5c79b101fa3c9e9c536388639a...8bd66d27c07e30d1f4d9e6dd57b075bca499bf2e

MOTION ENDS

The procedure for approval of this ballot is as follows:

Discussion Period (14+ days)

Start Time: 2024-April-09 16:00 UTC
End Time: After 2024-April-23 15:59 UTC

Voting Period (7 days)

Start Time: TBD
End Time: TBD



smime.p7s
Description: S/MIME cryptographic signature
___
Netsec mailing list
Netsec@cabforum.org
https://lists.cabforum.org/mailman/listinfo/netsec