v1.4 Roadmap

👉 @jetstack/team-cert-manager is invited to edit this PR's description and update the roadmap.

This issue is a place to record our ideas of what the v1.4 release will be made of. The timeline is:

Date
Event

Wed 15 April 2021
v1.4 milestone triage party* :heavy_check_mark:

Wed 28 April 2021
v1.4.0-alpha.0 :heavy_check_mark:

Wed 12 Thu 13 May 2021
v1.4.0-alpha.1 :heavy_check_mark:

Thu 27 May 2021
v1.4.0 code freeze starting at 23:59 BST

Fri 28 May 2021
v1.4.0-beta.0

Fri 11 June 2021
v1.4.0 final release

*in triage parties, we go over the backlog of issues and PRs and pick the ones that should go into the v1.4 milestone.
Goals for v1.4
These goals are a way to structure the v1.4 milestone. Although the GitHub milestone is still where we track individual pieces of work, I propose to have a couple of high-level goals that give us and the community more visibility as to our "agenda".
For this release, I propose the four following areas:

[x] Approval API. We want to continue the work we started on the Approval API; among others, we want to be presenting an out-of-tree approver that people can start using. @JoshVanL is leading the push towards the Approval API. You can follow the work at:

[x] cert-manager/policy-approver (the out-of-tree approver published v0.1.0-alpha.0 on Reddit, Slack)
[x] Posted on reddit
[x] https://github.com/jetstack/cert-manager/issues/3908#issuecomment-824714528 (PRs to the  known external issues)

[ ] Release automation. When releasing v1.1, v1.2, and v1.3, we realized that our manual release process prevents us from releasing often. @jakexks is driving this push towards more automation. You can follow the work at:

[x] cert-manager automation drive
[ ] Create cert-manager specific testing / release infrastructure (https://github.com/cert-manager/release/issues/27)
[ ] The cmrel needs to be updated to the new chart mechanism (https://github.com/jetstack/cert-manager/issues/3934) -> TBD @wallrj
[ ] Release jobs as containers (TBD link issue @jakexks) -> TBD @maelvls

[ ] Ease the onboarding of new contributors: New contributors have raised the fact that the learning curve for contributing to cert-manager is high. Epic: https://github.com/cert-manager/website/issues/549

[ ] https://github.com/cert-manager/website/issues/543: Have a getting-started guide (proposed by Richard Wall)
[ ] https://github.com/cert-manager/website/pull/548: Rework https://cert-manager.io/docs/concepts/certificaterequest with instructions for writing your own approver (proposed by Mael)

[ ] Market our new releases. (https://github.com/jetstack/cert-manager/issues/3901)

The approval API needs to be rolled out to all known external issuers:

[ ] step-issuer:

[ ] PR opened
[ ] New release with approval API
[ ] Update cert-manager.io docs

[ ] aws-pca-issuer:

[ ] PR opened
[ ] New release with approval API
[ ] Update cert-manager.io docs

[ ] awskms-issuer:

[ ] PR opened
[ ] New release with approval API
[ ] Update cert-manager.io docs

[ ] origin-ca-issuer:

[ ] PR opened
[ ] New release with approval API
[ ] Update cert-manager.io docs

[ ] google-cas-issuer:

[ ] PR opened
[ ] New release with approval API
[ ] Update cert-manager.io docs

[ ] freeipa-issuer:

[ ] PR opened
[ ] New release with approval API
[ ] Update cert-manager.io docs

[ ] ADCS Issuer:

[ ] PR opened
[ ] New release with approval API
[ ] Update cert-manager.io docs

Released https://github.com/jetstack/cert-manager/releases/tag/v1.4.0-alpha.0 :tada:

Not sure whether it should be part of the v1.4 roadmap, but I created an epic "Effort towards a more user-friendly website #549
". Just wanted to let you know 😅

I'm one of a new user adopting cert-manager.  I find it very unusual that cert-manager project seems to not promote reasonable defaults, leaving it to the users to figure out and explicitly configure best practices configuration.
https://github.com/jetstack/cert-manager/issues/3954 : security best practice of rotating keys in CSR for cert renewals, not sure why this is not the default ?
https://github.com/jetstack/cert-manager/issues/3958 : same here,  CertificateRequest seems like a internal implementation detail, why not default the GC behavior to cleanup old revisions automatically ?

👉 @jetstack/team-cert-manager is invited to update this issue.

Release plan (release date: 11 June 2021)
Before the release party:

[ ] Create an upgrade page similar to https://cert-manager.io/docs/installation/upgrading/upgrading-1.0-1.1 and merge it into release-next before the release
[ ] Update release process with "do not fast-forward to master after our first beta" (https://github.com/cert-manager/website/pull/585) (can be merged into release-next branch before the release party)
[ ] Update (release-next branch) the website's FAQ since built-in CSR resources are now usable with a CA issuer (can be merged into release-next branch before the release party)
[ ] Update the supported-releases page with 1.4 (can be merged into release-next branch before the release party)

After the release party:

[ ] Website: merge release-next into master
[ ] Merge the 1.4 Helm chart PR that was created by cmrel

Today is the day we had planned on releasing 1.4.
After a discussion in the standup, we decided to push back the release to Tue 15 June 2021 and to have v1.4.0-beta.1 released today.
Rationale: Richard Wall made the point that https://github.com/jetstack/cert-manager/pull/4040 introduced an "unexpected" change in the API where the renewBefore field would get overridden with another "sane value" (1/3 of actual duration) when the given renewBefore was bigger than this "sane value".
Two people (Johan Gonzalez and James Munnelly) confirmed that having a "sane value" that would override the user value would be unexpectedly coming from cert-manager.
As Richard pointed out, reverting #4040 would also require another beta since this revert is not trivial. Furthermore, this fix is important to us since it the most vital part of cert-manager (the renewal of certificates) for many Vault users.
The plan:

Irbe to work on https://github.com/jetstack/cert-manager/pull/4092 and Richard to review and to merge before this afternoon,
Josh to release v1.4.0-beta.1; the plan is to fast-forward to master and to do a new "code freeze" until Tue 15 June 2021.

cert-manager 1.4 has been released on Tuesday, I'll now close this issue.
/close


@MainActor closure type description adds '@Sendable' to the description starting from swift 6

Description
When printing type info of @MainActor () -> Void, then, @Sendable is added inside type description when executed in swift 6.
Reproduction
print((@MainActor () -> Void).self) // prints: "@MainActor @Sendable () -> ()" instead of "@MainActor () -> ()"

Expected behavior
'@Sendable' should not be added to the description.
We should have consistent behavior across swift versions, type descriptions should be same in both swift 6 and swift 5.10
Environment
On swift 6.0 its a bug
On swift 5.10 works ok
Additional information
No response

We should have consistent behavior across swift versions

Swift 6 is a new major versions. Breaking changes are expected and allowed per SemVer 2.0.
A big point of Swift "6" is to be able to release some breaking changes, otherwise there was nothing wrong with the next Swift version being "5.11".

I'm not even sure if string representation of types is considered part of the API (probably not).
I can still imagine that the Swift team doesn't want to annoy users by changing descriptions all the time even if they are not considered breaking.
But since this is a new major version, such a small change should be fine even after those considerations.

But when I try to get type info out of some framework - then @Sendable is missing, even if i am using swift6, for example:

That is not consistent


x/mobile: gomobile init fails to download ndk on x86 host

Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (go version)?
go version go1.7.4 linux/386
What operating system and processor architecture are you using (go env)?
GOARCH="386"
GOBIN=""
GOEXE=""
GOHOSTARCH="386"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/max/dev/workspace/go"
GORACE=""
GOROOT="/home/max/dev/go"
GOTOOLDIR="/home/max/dev/go/pkg/tool/linux_386"
CC="gcc"
GOGCCFLAGS="-fPIC -m32 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build501597397=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
What did you do?
I'm trying to install gomobile using https://github.com/golang/go/wiki/Mobile as a manual.
Running (gomobile init) ends up with error message:
"gomobile: error fetching https://dl.google.com/go/mobile/gomobile-ndk-r12b-linux-x86.tar.gz, status: 404 Not Found"
Looks like it just can't find proper ndk to download. Is there any known fix or workaround for this?

To the best of my knowledge, the NDK dropped 32-bit support on Linux quite a few releases ago. They still seem to offer 32-bit builds for Windows, though.

32-bit Linux is not supported anymore. We should die with a proper error message saying it is not supported.

@rakyll
No way to get to work with an outdated ndk for 386?
Something like "linux/386 ndk is outdated and is not supported by gomobile anymore. Use with caution"

There is no way to override the NDK location right now, but you should be able to override CC, CXX, CGO_CFLAGS, CGO_CPPFLAGS and CGO_LDFLAGS individually to target an earlier version of NDK toolchain.


The link for storepatcher.exe appears on Google's Unsafe Sites list

https://transparencyreport.google.com/safe-browsing/search?url=https:%2F%2Fdocs.dungeonsworkshop.net%2Fgettingstarted%2F
What's going on with that?  Does storepatcher have malware??

When scanning it with Windows Defender...

When scanning with Windows Defender....

The storepatcher.exe is a powershell script put through a program called PS2EXE. This program was recently been flagged because someone used it with their virus script. I did not write the script for storepatcher.exe but I have seen the code for it and can confirm it does not have malware nor dishonest intent. This red flag has been reported to the anti-virus websites as a false positive but these things take time to get cleared.


[Bug]: MultiSelect dropdown gets unclickable after deleting array item from JSONForm

Is there an existing issue for this?

[X] I have searched the existing issues

Description
https://www.loom.com/share/1fe8df2df19942c9b7656fd31e30a5ba
P.S: Issue is happening on view mode as well and only happening for Multi select type field
Steps To Reproduce

Add JSON form onto canvas
Add  new field as Array
Add Multi select type field inside array items
click on 'Add New' in form to add more array items
Now delete 1 entry and Observe that multiselect dropdown is not clickable

Public Sample App
No response
Version
Cloud / Production

@ashit-rath can you triage this?

Stats

Stat
Values

Reach
72

Effort (months)
1