This can be closed. rget is going to execute on a design to support arbitrary URLs https://github.com/merklecounty/rget/issues/10#issuecomment-555630002

/close

Wrote a design doc on this. I think it is clear there is utility for rget but supporting arbitrary URLs is a critical feature and to do that we have to get rid of the SHA256SUMS + Let’s Encrypt cert hack.

+1 to mirroring. I tried to do a demo and was so confused by the default behavior.

Yes, last time I looked into all of this when I set it up @googlegroups.com can't nest.

On Fri, Nov 15, 2019 at 4:08 PM Tim Allclair (St. Clair) < [email protected]> wrote:

I was under the impression that groups outside an apps domain couldn't be nested, but I'm no expert on the matter...

— You are receiving this because your review was requested. Reply to this email directly, view it on GitHub https://github.com/kubernetes/security/pull/59?email_source=notifications&email_token=AAAIGCERLNUXQRWXACZL7STQT42WLA5CNFSM4JN65PM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEHC6EY#issuecomment-554577683, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAIGCHTNY7O7AXWBYPFYB3QT42WLANCNFSM4JN65PMQ .

/lgtm

The audit is now underway with @mitake @gyuho involved and all etcd maintainers subscribed to updates.

I think Mitake should be involved since he worked on some of the auth stuff originally.

On Fri, Nov 1, 2019 at 7:01 AM Sahdev Zala [email protected] wrote:

@caniszczyk https://github.com/caniszczyk thanks! Please consider @xiang90 https://github.com/xiang90 @gyuho https://github.com/gyuho and myself for now. Also please keep @philips https://github.com/philips in the loop. I believe we can change one or two individuals here if needed due to schedule conflict/travel etc? /cc @xiang90 https://github.com/xiang90 @gyuho https://github.com/gyuho @philips https://github.com/philips - hope this is fine per earlier discussion. Should we ask Mitake as well? Thanks!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/etcd-io/maintainers/issues/18?email_source=notifications&email_token=AAAIGCCSMA4XNT4TLYEQUA3QRQZC7A5CNFSM4IYOJE22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEC276YY#issuecomment-548798307, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAIGCBAHUNIIO3FDCWB4GTQRQZC7ANCNFSM4IYOJE2Q .

Done.

On Wed, Oct 30, 2019 at 2:56 PM Victor Trac [email protected] wrote:

@philips https://github.com/philips I spoke with @idvoretskyi https://github.com/idvoretskyi about this over the weekend, and we both think it may be better to put the go code for discoveryserver into its own repo, leaving the infra/meta stuff in this repo.

I don't have access to do this. Can you make a new discoveryserver repo and add me and @eduartua https://github.com/eduartua as a writer? I'll work with @eduartua https://github.com/eduartua to commit this code there.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/etcd-io/discovery.etcd.io/pull/15?email_source=notifications&email_token=AAAIGCHPLR6JRTGVLCALIBDQRH7J5A5CNFSM4JE6V7D2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECV4YRY#issuecomment-548129863, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAIGCEE3JVWZZQNHYABSN3QRH7J5ANCNFSM4JE6V7DQ .

@cblecker rebased PTAL and approve

Cloudbuild is probably fine. Quay was working fine too.

On Tue, Oct 22, 2019 at 8:18 AM Eduar Tua [email protected] wrote:

@philips https://github.com/philips I'm going to explore the repository and see how we can isolate the discovery server go code. Do you think this is a good approach to implement the cloudbuild pipeline?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/etcd-io/discovery.etcd.io/issues/12?email_source=notifications&email_token=AAAIGCFMSOGUG5TIGD5UIE3QP4KSNA5CNFSM4IUEU2KKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEB6D6VQ#issuecomment-545013590, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAIGCBIDNLRBEQFL4UCM43QP4KSNANCNFSM4IUEU2KA .

lgtm

+1 /lgtm

Yes, sounds good.

On Mon, Oct 21, 2019 at 3:58 PM Victor Trac [email protected] wrote:

@philips https://github.com/philips You're right about these two issues.

1. There's a 10 min TTL on the A record for discovery.etcd.io at the moment. We can reduce to to 60s prior to the migration to reduce the likelihood of this happening, but it's not going to completely eliminate the issue. Also, my intuition says that cluster members will be using the same DNS server (since they'll likely be in the same datacenter), so it seems exceedingly unlikely that a member will resolve an IP address prior to TTL expiration (with the old IP) and then another member will grab the new IP after expiration.
2. I can see this happening for a very slow to bootstrap cluster. If a member starts and resolves the old discovery service and then subsequent members don't bootstrap until after the TTL refreshes to the new discovery service, then this will happen. Again, this seems exceedingly unlikely if end-users are using automated processes to bootstrap the cluster, since the cluster members will likely come up fairly simultaneously.

The traffic is fairly low, and we'll do the DNS swap during low-traffic periods. We'll also notify the dev mailing list. There are (time) expensive technical ways to possibly mitigate these concerns further, but they don't seem worth it to me. Does this address your concerns?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/etcd-io/discovery.etcd.io/pull/14?email_source=notifications&email_token=AAAIGCDUVRYB6OC4WKR2FZ3QPYXY5A5CNFSM4JCMSWUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEB4B32I#issuecomment-544742889, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAIGCDTILHXBGUDRCGGV2LQPYXY5ANCNFSM4JCMSWUA .

xref https://github.com/kubernetes/community/pull/4188#issuecomment-544728369

@lukehinds you need to file this issue: https://github.com/kubernetes/org/issues/new?assignees=&labels=area%2Fgithub-membership&template=membership.md&title=REQUEST%3A+New+membership+for+<your-GH-handle>

See this doc: https://github.com/kubernetes/community/blob/master/community-membership.md#member

Add via https://github.com/kubernetes/security/pull/51

<!-- Thanks for sending a pull request! Here are some tips for you:

• If this is your first contribution, read our Getting Started guide https://github.com/kubernetes/community/blob/master/contributors/guide/README.md
• If you are editing SIG information, please follow these instructions: https://git.k8s.io/community/generator You will need to follow these steps:
  1. Edit sigs.yaml with your change
  2. Generate docs with make generate. To build docs for one sig, run make WHAT=sig-apps generate -->

/approve

Via 18e94b8c9a50502a1b4db8aefe98538a9e850d69

@victortrac How are you going to migrate the data? There are two issues with migrating to a new cluster:

1. DNS split horizon for the length of the domain TTL will cause boot strapping to fail
2. All of the data will be lost so any cluster mid-bootstrap will fail

If doing this migration is the only option please do send an email to [email protected] to give everyone a heads up.

I can't review the terraform code however, I don't know it well enough anymore.

/lgtm /approve

thanks xiang. It would be great to get a few dates together that would work for people to start so the CNCF can start the contract drafts.

On Thu, Oct 17, 2019 at 10:59 AM Xiang Li [email protected] wrote:

assigned to Guyho and myself.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/etcd-io/maintainers/issues/18?email_source=notifications&email_token=AAAIGCEXXOJURPV3S3AWBELQPCRXPA5CNFSM4IYOJE22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBQ7RBY#issuecomment-543291527, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAIGCGBEQVMETEMOP4UK63QPCRXPANCNFSM4IYOJE2Q .

Pingd @gyuho about this today.

We need on-boarding and off-boarding docs for committee members. We have some of it documented here:

https://github.com/kubernetes/security/issues/16 https://github.com/kubernetes/security/issues/11

https://github.com/kubernetes/security/pull/37 fixes this

I want to nominate Luke Hinds to join the Product Security Committee as a full member. He has been an associate member since June 26th 2019 and in that role over the last three months he has helped on a number of tasks including:

• Coordinating CVE-2019-11251 announcement
• Writing Kubernetes Security Committee on-boarding guide

Our process for accepting this nomination is lazy consensus and I will close the round of consensus on Oct 18th, 2019 to leave time for any comments or question. If the nomination is accepted Luke will take on the full responsibilities of a Security Committee member and take on a weekly rotation for [email protected] on-call rotation.

@zacharysarah Any more information on why this was closed?

/lgtm /approve

(for old times sake)

@dims is now sc1.

@dims please put up a PR to update the README.

The SC1 and SC2 accounts are meant for one off maintenance of the kubernetes.io GSuite system. @jbeda and @philips currently own 1 and 2 respectively. We need to hand them off to new steering members.

See https://groups.google.com/forum/#!topic/kubernetes-dev/1kZvBDGhSCU

LGTM

Added extra path information when a non-ghar symlink is found so that user can understand where the problem is.

Before this commit it read: ".bashrc: can't handle non-ghar symlinks." After this commit it reads: "Linking ~/.bashrc to ~/Projects/ghar/ghar/.bashrc: can't handle non-ghar symlinks."

merged, thanks for the contribution and sorry for the long delay!

Python 3.6.0 reports an error when running ghar. Removing the \ before the R on the regex line fixes it for me:

Traceback (most recent call last):
  File "/home/jwong/ghar/bin/ghar", line 359, in <module>
    main(args)
  File "/home/jwong/ghar/bin/ghar", line 347, in main
    _init_repos()
  File "/home/jwong/ghar/bin/ghar", line 340, in _init_repos
    repos.append(Repo(os.path.join(root, dir)))
  File "/home/jwong/ghar/bin/ghar", line 229, in __init__
    self.is_collection = self._is_collection()
  File "/home/jwong/ghar/bin/ghar", line 151, in _is_collection
    if re.match("^\.git(ignore|modules)?$", f) or re.match("^\README.*$", f) or re.match("^\.travis.yml", f):
  File "/usr/lib/python3.6/re.py", line 172, in match
    return _compile(pattern, flags).match(string)
  File "/usr/lib/python3.6/re.py", line 301, in _compile
    p = sre_compile.compile(pattern, flags)
  File "/usr/lib/python3.6/sre_compile.py", line 562, in compile
    p = sre_parse.parse(p, flags)
  File "/usr/lib/python3.6/sre_parse.py", line 856, in parse
    p = _parse_sub(source, pattern, flags & SRE_FLAG_VERBOSE, False)
  File "/usr/lib/python3.6/sre_parse.py", line 415, in _parse_sub
    itemsappend(_parse(source, state, verbose))
  File "/usr/lib/python3.6/sre_parse.py", line 501, in _parse
    code = _escape(source, this, state)
  File "/usr/lib/python3.6/sre_parse.py", line 401, in _escape
    raise source.error("bad escape %s" % escape, len(escape))
sre_constants.error: bad escape \R at position 1

fixed! Sorry for the long delay! I owe y’all a coffee sometime :-P

In my mind we either:

1. Remove approvers completely.
2. Rename maintainers to approvers.

A reviewer is generally someone who is on the ladder towards maintainership but isn't experienced/trusted enough to merge code themselves.

IMHO we should just remove approvers because the language of "maintainers" has been with the project since day 1.

On Thu, Sep 26, 2019 at 9:09 AM Sahdev Zala [email protected] wrote:

lgtm.

One discussion: Was there a discussion on the concept of approvers? Have we needed this additional abstraction in the past? And did Fanmin and Anthony agree to be approvers?

@philips https://github.com/philips thanks, and good points for discussion something I also thought myself too but I decided to kept the roles the same way except removing overlapping of members between roles. Now that you mentioned, I will reach out to Fanmin and Anthony for their interest. Also, though current roles provides good distinction, most projects only have two (maintainers/approvers and reviewers). I personally is totally good in keeping only two roles (maintainers and approvers/reviewers) if everyone is fine with it.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/etcd-io/etcd/pull/11175?email_source=notifications&email_token=AAAIGCAD4RVHB4S2JOLOLKDQLTNB7A5CNFSM4IZRZ3CKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7WDUIA#issuecomment-535575072, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAIGCEYGE2HWGOM4SZCSVDQLTNB7ANCNFSM4IZRZ3CA .

lgtm.

One discussion: Was there a discussion on the concept of approvers? Have we needed this additional abstraction in the past? And did Fanmin and Anthony agree to be approvers?

sounds good, thanks Sahdev

On Tue, Sep 24, 2019 at 3:28 PM Sahdev Zala [email protected] wrote:

Also, as we discussed renaming won't be easy and probably not a good idea. So I will close the issue with this setting change. Thanks!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/etcd-io/maintainers/issues/14?email_source=notifications&email_token=AAAIGCAKQFMCWM4ANKA7TEDQLKIA7A5CNFSM4IG5RLWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7P74II#issuecomment-534773281, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAIGCBDAH2SHIANLN64EZLQLKIA7ANCNFSM4IG5RLWA .

/lgtm /approve

Awesome thanks

On Sat, Sep 21, 2019 at 7:32 PM Theodore Dubois [email protected] wrote:

Closed #405 https://github.com/tbodt/ish/issues/405.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/tbodt/ish/issues/405?email_source=notifications&email_token=AAAIGCFJP5HK3GG3ZGPKI3LQK3KLVA5CNFSM4HWDIW3KYY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGOTYMLYEI#event-2652421137, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAIGCBTZ4XL74NMAJNF6C3QK3KLVANCNFSM4HWDIW3A .

Yes, but can you squash everything down?

@spzala you are now an owner.

@swamymsft could you please add the application to the commit message as done with the canonical: https://github.com/kubernetes/security/commit/49b5e06484ebf71ff27f08f2212760e2617ab8ac#diff-49e086cea35a7ca0f86fae6ba77880c9

This looks fine. Approved.

@swamymsft can you format this into a PR against https://github.com/kubernetes/security/blob/master/private-distributors-list.md

Fix https://github.com/etcd-io/website/issues/44.

Other versions do not have v2 docs.

When I go to the documentation of etcd3 I expect to find the most updated docs, older versions should be easy to find. Currently, the default is documentation of etcd2

The links to updated documentation are broken:

Makes sense.

Is there automation that caused this to be copied that needs to be updated as well?

@hexfusion could you clarify what the Jenkins infrastructure changes might be for this?

My memory is that we cross compile the other archs for the docker images. But, @nayana-ibm was thinking that s390 build machines were needed.

• [ ] Identify a lead for the project
• [ ] Identify 1-3 maintainers to help guide the auditors
• [ ] Maintainer files a CNCF Service Desk ticket to request a security audit
• [ ] Wait
• [ ] Work with security audit team
• [ ] Work with CNCF to publish results

cc @spzala

releases have been cut with this new import path.

Looks like inotify is missing. I don’t know the ioctl code off hand.

dmesg gives me:

# dmesg
unknown ioctl 5413
unknown ioctl 5413
unknown ioctl 5413
unknown ioctl 5413
unknown ioctl 5413
22 missing syscall 332

This should be easier now that there is an API of module versions: https://index.golang.org/

Follow-up question for eventual KEP: "Why do we care whether a project is in the CNCF?". Reading the current policy there are several references to policies that differ whether a project is a CNCF project:

Adding a tutorial that explains how to perform a task using a vendor-specific product or an open source project that is not a CNCF project or a project in the kubernetes or kubnetes-sigs GitHub organizations

Content that describes a non-Kubernetes project Allowed: Adding a brief introductory paragraph about a CNCF project or a project in the kubernetes or kubernetes-sigs GitHub organizations; the paragraph may contain links to the project Not Allowed: Adding content describing an open source project that is not a CNCF project or a project in the kubernetes or kubnetes-sigs GitHub organizations

Content that simply links to information about a non-Kubernetes project Allowed: Linking to active CNCF projects Not Allowed: Adding content describing a vendor-specific product Adding content describing an open source project that is not a CNCF project or a project in the kubernetes or kubnetes-sigs GitHub organizations

This is troubling to me because a non-goal of the CNCF to is to host every piece and part required to make Kubernetes technically successful. It may happen but it shouldn't be a consideration for quality user facing docs.