ViolationNone of the descendent elements with "treeitem" role is tabbable

Detailed description

Describe in detail the issue you're having.

None of the descendent elements with "treeitem" role is tabbable

Is this a feature request (new component, new icon), a bug, or a general issue?

 bug

Is this issue related to a specific component?

role="treeitem"

What did you expect to happen? What happened instead? What would you like to see changed?

What browser are you working in?
Mozilla 106.0.5v
What version of the Carbon Design System are you using?
"carbon-components": "^10.49.0",
"carbon-components-angular": "^4.59.14",

What offering/product do you work on? Any pressing ship or release dates we should be aware of?

Steps to reproduce the issue

Step one
Step two
Step three
etc.

Additional information

Screenshots or code

Notes

It has resolved automatically, so closing the issue.


devops pipeline run exception

Describe the Bug
Q1、devops pipeline still running but jenkins task already completed,and can't stop in control plane, when i run a new pipeline task,it always waiting.only delete the pipelinerun crd resource task will start
Q2、start a pipeline task，there come out  two sample task and i also can find two different  pipelinerun crd  name with same ‘’devops.kubesphere.io/jenkins-pipelinerun-id‘’
Versions Used
KubeSphere: 3.2.1
Kubernetes:v1.20.4
Expected behavior
Q2:

hi @zj452008181 , glad to see you here. This is a known issue of v3.2.1. It was fixed. Please feel free to verify it in the v3.3.0-alpha.
/kind support

thanks for your reply，one more question：i configured ldap in my host cluster，and i can use ldap user to start host cluster's pipeline，but can't run member cluster's pipeline。i check the kubesphere-config:devops:password in two cluster,they have same value.only found some error in ks-controller-manager  log,please give some suggest
member's ks-controller-manager:
`E0509 17:19:09.312632 1 user_controller.go:347] GET http://devops-jenkins.kubesphere-devops-system.svc/role-strategy/strategy/getRole/?roleName=admin&type=globalRoles: 401

<meta http-equiv=“Content-Type” content=“text/html;charset=utf-8”/>
Error 401 Invalid password/token for user: admin

HTTP ERROR 401 Invalid password/token for user: admin

URI:/role-strategy/strategy/getRole/
STATUS:401
MESSAGE:Invalid password/token for user: admin
SERVLET:Stapler`

There're two potential issues and solutions that you can try:

The account of LDAP was not synced successfully

Possible solution: Reset the password of your account

The JWT token was wrong

Possible solution: Restart the deployment of devops-apiserver and devops-controller

@LinuxSuRen found out！The JWT token in devops-config was different between two cluster，i copy host‘s  JWT token to member,and restart devops-apiserver and devops-controller,first problem dont resolve，but ks-controller-manager dont print any error，so i just try log out and use ldap user login，problem resolved.thanks a lot

I still feel confused about the JWT issues. Please let me know if you found any pattern that can help us to fix it for good.

maybe it changed when i upgrade the cluster,i don't sure what happend,but i tried restart the ks-installer to repair this issue，however it dont work.there has no modify time shows in configmap ui，maybe it's useful when i check the configmap.

Actually, the secret randomly issue was fixed by https://github.com/kubesphere/ks-devops/pull/591

I'm going to close this issue due to it was fixed in v3.3.0. Please feel free to open this issue again if you believe it still exists in v3.3.0.
/close


Roadmap update for TUF support

Is it possible to get an update on the development roadmap about when TUF or other encryption support might be deployed? Thanks!
Also, it appears that tomorrow will be 6 years since January 5, 2013.

Thanks - good question.
I note that TUF is one of the options noted under Add support for API keys · Issue #994 · pypa/warehouse which appears under the "Cool but not urgent" milestone.
I agree that TUF addresses many of the nicely described PyPI-specific concerns that @dstufft wrote way back on 23 July 2013: Why Package Signing is not the Holy Grail

I believe that the package signing issues stated can be resolved and in 2019 our internet depends on the security of infrastructure such as PyPI. If there is not a roadmap for TUF support, I'm going to look at solving the problem.

Perhaps we can evaluate integration with third-party services for verification?
Keybase.io helps create trust by building a verified profile attached to a GPG key across multiple services.
GitHub handles gpg signature verification for commits, refs, releases, etc. (although, your GH pgp key is kept in your GH settings... 2fa could help mitigate unauthorized account access)
Falling back, you can have a PGP key on MIT's PGP keybase which forwards a public key to key servers around the world.
Now, this does assume putting trust in third-party services themselves (and the author of the actual PGP key), but the chances are very slim that your PGP key would be replaced on multiple services at once. The biggest issue is an author being unable to secure their private key (no password, weak password, bad private key handling, etc...), or their account becoming compromised (e.g. GitHub).
This doesn't solve the problem on PyPi's side of verifying someone, although PyPi shouldn't have to verify anyone. PyPi should host the package. It should display information about the package being signed (or unsigned), the package's origins and contents, and whoever is downloading the package should check that key against their trusted sources.
In the past, PyPi has hosted malicious code. Of course, this happens. It is expected. Other package managers suffer as well.

I'm sure we all can go on about this.
Sure, PGP signing doesn't guarantee security. It doesn't guarantee verification. It doesn't even guarantee safe, robust, reliable, ... code. PGP is just a part of a solution to of a complex problem.
As signing becomes supported by major services (package maintainers, source code repositories, document services, ...), a trust network (keybase, key servers, ...) can be utilized to help security-minded users track where their packages are coming from.
If a user or a maintainer doesn't care about signing, it doesn't have to be enforced at the beginning, If the feature is there, people will use it.

I am convinced that this problem is tractable and I think the key here is that EigenTrust can provide us a mathematical model to get started.
We already have some data in the git commit history. When someone signs a git commit there is an eigentrust metric that can be calculated for all of the previous signed commits. There is reason to believe that causality and techniques like Bayesian inference may also be useful here where multiple commits are signed by a key we do not yet trust, but are temporally followed by a key we do trust. We can also federate our memories of git history and checksums to detect anomalies and attacks on infrastructure.
Sites like github and sr.ht can already provide trust metrics by validating that an email address is connected to a GPG key. We can formalize and automate our existing manual heuristics for validating packages.
Further I think we should start thinking about metadata for developers and organizations that produce software. Organizations can maintain a META-DEV repository that contains the PGP signing keys of active developers, key revocation information, and per repository release manager designation. Developers can also maintain a META-DEV repository that contains yaml (or whatever) metadata linking to a developers twitter / blog / instagram / keybase / identi.ca / matrix / Mastodon / xmpp / whatever where the PGP fingerprint can be posted.
Perhaps we need to start building keyrings in OS native packaging formats (.deb, .rpm, etc) so that trust can at least be established for the most critical python packages.
This is a complex problem but we need to take what small steps forward that we can instead of waiting another year to secure PyPI or even bother to figure out certificate pinning.

Thank you to everyone who's raised this issue and shared their thoughts and useful resources! And sorry for the slow response!
Short answer: we'll be discussing TUF & Warehouse much more in April.
Longer answer:
The folks working on Warehouse have gotten funding to concentrate on improving Warehouse's security, and have kicked off work (funded by the Open Technology Fund) towards multi-factor auth, API keys, and an audit trail. And -- to quote the blog post --

Facebook... has provided the Python Software Foundation with a monetary gift that will be used to fund the development and deployment of enhanced security features to PyPI....

The PSF Packaging Working Group plans to use these funds to implement highly requested security features in PyPI such as cryptographic signing and verification of files uploaded and installed from the index. Additionally, systems for the automated detection of malicious uploads will lower the time to response and improve the resiliency of PyPI against attacks such as "pytosquatting".

This work will be undertaken in the second half of 2019 but planning will begin in the second quarter of the year.

We anticipate that in mid-April (so, basically within about a month) we'll be announcing a formal Request For Information to ask people to tell us about their interest in being contracted to do this work, and that part of that discussion will be further, more detailed conversations about whether TUF is the right tool for this job. So please watch for that, on this issue and on https://discuss.python.org/c/packaging .
(cc @pradyunsg since I think you're interested in this.)

From the TUF side, we're very interested in moving this forward.  Let us know what we can do to help!

https://motherboard.vice.com/en_us/article/pan9wn/hackers-hijacked-asus-software-updates-to-install-backdoors-on-thousands-of-computers

Same, happy to help with this, just let us know how.

"PyPI security work: multifactor auth progress & help needed"
https://discuss.python.org/t/pypi-security-work-multifactor-auth-progress-help-needed/1042/10

At PyCon sprints several people spoke about the potential future of TUF in Warehouse and Python packaging, and put notes at https://docs.google.com/document/d/1Wz2-ECkicJgAmQDxMFivWmU2ZunKvPZ2UfQ59zDGj7g/ .

Thanks, Sumana!
I'm happy to help with the design and coding for this
project @lukpueh @awwad

I'll also devote whatever time is necessary to get this done

Thanks for putting together our notes, @brainwane! It was a pleasure meeting you guys at PyCon. @ewdurbin, any news on the RFI?
@ofek and @trishankatdatadog, your help will be very much appreciated.

See the PSF's new blog post & the open RFP. Later this year, PyPI wants to start:

Implementation of PEP 458 once accepted to add integration of The Update Framework to PyPI
Development of either a stand alone service or code in the Warehouse codebase to create, sign, serve, and handle caching concerns for TUF metadata
Development of necessary code in the Warehouse codebase to integrate TUF metadata and signing

This means we need to move PEP 458 from "Deferred" to "Accepted" status. Per @ewdurbin's guidance, this means we'll need to get PEP 458 revised, as necessary, to pin down specifics, such as key distribution (who, where, how many?) plus any technical choices that TUF leaves up to implementations. To revise PEP 458 and get it accepted, we'll need to collaborate with previous implementers and other experts.
Given the RFP timeline the latest we should get the PEP accepted is 2 December 2019, but I'd much prefer we get it accepted by mid-October.

Thanks for the update, @brainwane!
@JustinCappos @lukpueh Ok, so we have our work ahead of us. I have work obligations to meet, but can devote whatever time I can for this. Let's plan ASAP.

Let me know if you need more assistance, I'd be glad to help!

Now that the PEP is back in Draft status*, I think the next steps are for one or more of the PEP authors to:

refresh the References/Discussion headers on the PEP with relevant discussions from https://discuss.python.org/c/python-software-foundation/pypi-q4-rfi and https://discuss.python.org/t/prerequisites-vetoes-improving-packaging-security/2196 and anywhere else that the PEP was discussed
post to https://discuss.python.org/c/packaging about the PEP (and cross-post to pypa-dev and distutils-sig to start a new discussion and, eventually, ask for acceptance

@dstufft is now the BDFL-Delegate for this PEP so it'll have to be the other authors (@trishankatdatadog, @vladimir-v-diaz, @JustinCappos) who push this forward. If we want to get any revisions done and get Donald to accept the PEP by mid-October then you should start the steps above in the next couple days, in my opinion.
* the version at python.org needs to be re-generated, but https://github.com/python/peps/pull/1177 was accepted

A few of us had a chat today and are working to update the PEP (https://github.com/python/peps/pull/1178 is part of that), and one or more of the PEP authors will be reaching out to @ewdurbin with a few questions.

@brainwane FYI - I'm happy to help with implementing functionality on the client side (i.e. pip) when we get to that point.
I think we'd want to create a tracking issue on pip's issue tracker to have implementation related discussions there, after the PEP is accepted (AFAICT how clients interact with TUF-enabled PyPI is covered by the PEP and would be discussed in the discussions on discuss.python.org).

Hi @ewdurbin and @dstufft, we have a few questions for which we could use your help:

By "key distribution," do you mean who manages how many keys and where on the PyPI side? Do you also mean how package managers such as pip would determine which keys to trust in the first place?
What is the current deployment process for Warehouse? This will help us determine how to edit the PEP to discuss how to update the TUF-specific code in Warehouse.
What else would you like to see more about, or see changed in the PEP?

Thanks for your time!

@ewdurbin @dstufft I have also sent you both an email about a conference call this week, if possible. Thanks!

Current status: https://github.com/python/peps/pull/1203 is awaiting review from @dstufft to revise PEP 458. After that, there needs to be a discussion on https://discuss.python.org/c/packaging to get the PEP from "Draft" to "Accepted".
In order to make implementation easier, Dustin wants to work towards implementing #726 (removing Test PyPI from our infrastructure will make key stuff far easier). @di will be speaking more on that in the relevant issue soon.
And, starting in December, @ewdurbin will be managing the contractors who will implement TUF on PyPI. Then the first big key ceremony will be in April at PyCon North America -- if you haven't put PyCon on your calendar yet, you probably should! Conference registration will open later this month.

The TUF team is now responding to Donald's reviews, and has a discuss.python.org thread up where people can discuss the draft PEP and suggest it be accepted.
PyCon 2020 registration is now open. Tickets do sell out, so if you intend to go, you should register soon.

Thanks for all the feedback! We converted the document to a blog post that is available here.

The blog post looks great to me! Thanks everyone who worked on it! ^.^
It does explain the trade-offs pretty well IMO, as someone who has working knowledge of these topics, but does not have the understanding of these systems and the trade-offs between them, like @ncoghlan does. :)

the blog seems to imply that it's a good idea to use TUF+TL at the same time

[FYI: I'm CCing the post authors in case they want to weigh in here.]
I'd say that you could get some value by combining them, but you have to
weigh if it's more important to 1) have a list of packages released that is
somewhat harder to change but have a large potential for damage and no
secure way to recover (TL) or 2) be able to restrict damage when there is a
compromise and securely recover from such an attack (TUF).
You could use both together (which has higher operational overhead than
either separately) and see security benefits.  However, I'd certainly argue
TUF provides the far more important protections.
I'm not aware of any of the TUF deployments
https://theupdateframework.com/adoptions/ which have chosen to also use
TL.
On Tue, Feb 11, 2020 at 8:45 AM Thomas Grainger<EMAIL_ADDRESS>wrote:

the blog
https://ssl.engineering.nyu.edu/blog/2020-02-03-transparent-logs seems
to imply that it's a good idea to use TUF+TL at the same time
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/pypa/warehouse/issues/5247?email_source=notifications&email_token=AAGROD4RLJUK2FK6Y7WSNPDRCKTWTA5CNFSM4GNHO6P2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELMOTNI#issuecomment-584640949,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGRODYJO6LIGTVC5D6ZFXLRCKTWTANCNFSM4GNHO6PQ
.

Thanks for pinging us @JustinCappos
@graingert Right, I agree with Justin: for an open source repository like PyPI, using TUF gives you the guarantee you ultimately want: attackers not being able to tamper with packages signed w/ offline keys. We stress in that blog post that TLs don't give you this property out of the box. We recommending using a TL on top of TUF so that you an audit the TUF metadata, if necessary.

If everything was being signed with offline keys, then I also don't think a TL would add much.
However that isn't the situation that we expect to end up in, even if PEP 480 has been accepted and implemented. Instead, we expect the vast majority of packages to be signed by PyPI (with historical metadata protection provided via a TL), and a subset of publishers opting in to managing their own signing keys and gaining the full metadata protection offered by TUF.

If everything was being signed with offline keys, then I also don't think a TL would add much.
However that isn't the situation that we expect to end up in, even if PEP 480 has been accepted and implemented. Instead, we expect the vast majority of packages to be signed by PyPI (with historical metadata protection provided via a TL), and a subset of publishers opting in to managing their own signing keys and gaining the full metadata protection offered by TUF.

Right. I should note that only a few publishers (e.g., top 20% packages) need to opt-in to get a lot of bang for the buck (e.g., 80% of downloads). That said, adding a TL to record history wouldn't hurt.

Also TL would be a nice upgrade to the --generate-hashes/--require-hashes workflow as you'd only need to record the latest TL root. And no need for any public key cryptography

Also TL would be a nice upgrade to the --generate-hashes/--require-hashes workflow as you'd only need to record the latest TL root. And no need for any public key cryptography

Yes, at the risk of adding new, malicious versions of packages when the TL is compromised.

Only if you repin the TL, same with --generate-hashes

Hi all -- I think this conversation should probably be on the discussion thread on the PEP itself. Thanks!

@dstufft wrote today:

It looks like discussion about the actual meat and potatoes of this PEP has petered out. Unless someone has an objection, I intend to accept this PEP on Friday.

So, PEP 458 got accepted. @woodruffw @ewdurbin it looks like #7488 has not been merged yet -- is it waiting for something? I feel like I heard there was a securesystemslib issue blocking it but I'm not sure...

I feel like I heard there was a securesystemslib issue blocking it but I'm not sure...

Yep. The primary blocker on the securesystemslib side is API support for abstract storage backends, which is currently being tracked by https://github.com/secure-systems-lab/securesystemslib/pull/232. Those changes then need to be rolled into TUF, which hasn't begun yet.
The key generation and signing ceremonies also need to take place before #7488 can be fully deployed, although those can happen independently of any TUF/securesystemslib changes once I complete the runbook and provisioning scripts.

@woodruffw Out of curiosity, what is the intended storage backend?

Out of curiosity, what is the intended storage backend?

Warehouse currently uses Google Cloud Storage via the S3-compatible API for file storage (i.e., for uploaded packages), and my intent was to use it for TUF's metadata as well.

via the S3-compatible API

We actually just use the regular Cloud Storage APIs:
https://github.com/pypa/warehouse/blob/630ac09321d93a6867f2b801153f45a90ba50d58/warehouse/gcloud.py#L27
https://github.com/pypa/warehouse/blob/630ac09321d93a6867f2b801153f45a90ba50d58/warehouse/packaging/services.py#L171-L193

We actually just use the regular Cloud Storage APIs:

Whoops! My bad. Using the regular APIs should also be fine 🙂

Ah nice, I also use Google Cloud Storage for storage 😄
Does Warehouse run on Kubernetes? https://ofek.dev/csi-gcs/
Many orgs are beginning to use that, one of the most recent (public) ones is EdgeDB https://github.com/edgedb/edgedb-pkg/commit/0bcfeb97ff29834f5e674106254c4de7c0a41d0b

I see https://github.com/pypa/warehouse/pull/7488#issuecomment-638973770 mentions a few blockers that people are currently working on ("some bugs in the TUF reference implementation, namely missing roledb state when reloading the repository").

https://github.com/theupdateframework/tuf/issues/574
https://github.com/theupdateframework/tuf/issues/1045
https://github.com/theupdateframework/tuf/issues/1048

A few people are working on those, including @sechkova and @lukpueh and @trishankatdatadog. I'm sure they would welcome help.

I've been drafting the pip side of this and have some unsolved issues related to the 'warehouse client contract' -- what exactly does warehouse promise about urls?

where is tuf medata in relation to index url (link)
how to resolve tuf target name from a distribution download URL (link)
is it safe to assume that "project index urls" (like https://pypi.org/simple/django/) are directly under the main index url? (link)

The first one is a tuf-warehouse implementation detail that just should be agreed on. The other two are more questions about Warehouse 'client API' in general -- it's easy to hack something that works now but might be very painful in the future when Warehouse architecture changes. The links hopefully contain enough context. I would really appreciate comments on those (either here or in my issues).

@jku Thank you for these questions and related issues. They do seem important to pin down, but I'm a bit unclear as to how they fit in to pip, or indeed what the typical flow of "trust" thru pip is.  Can you point to the relevant sections of the PEP, or provide a bit more background (here or in the pip issues, as appropriate) on a few typical, relevant flows?

Too much Pip details in a Warehouse issue may be off-topic but I'll share my "work-in-progress design doc" (I was a bit hesitant to share as it's really just notes to myself but the first two pages should be readable):
https://docs.google.com/document/d/1Xqwoy0z0MyLh9eZHgSftozRB_sxjd1IbkIVtvolVkFI/edit?usp=sharing. The Implementation notes section maybe makes it easier to understand why I think the issues are relevant.
I'll start discussing this in detail with pip community very soon in https://github.com/pypa/pip/issues/8585: I was just hoping the warehouse client contract issues would have solutions in sight before that.
As far as "trust" in pip goes, this is my interpretation of the current implementation:

index url in pip.conf makes that server a trusted source of distribution URLs and distribution hashes
when a distribution is downloaded, it's trusted if the hash matches (this makes it hard for a malicious distribution mirror to implement attacks)

With TUF the very high level overview is:

index url in pip.conf makes that server a trusted source of distribution URLs
the same server is a source of updated TUF metadata: this updated metadata is only  trusted if there is a signature chain from earlier local metadata
when a distribution is downloaded, it is trusted if its hash matches the one found in trusted metadata

The pep goes into more detail but that is not really visible to pip: the TUF client updater component handles the complexity. The major improvement IMO is that an attacker able to modify project index files (e.g. https://pypi.org/simple/django/) in a warehouse server cannot fool clients into downloading/installing malicious URLs: the attacker would need access to the online signing keys as well. The secondary improvement is that even in the case of online signing key compromise, there is a recovery path.

just for awareness there is a simple cli implementation of tuf extant as well in rust at https://github.com/awslabs/tough

@jku thanks for sharing the doc, is there a mailing list where its appropriate to discuss this or can you update the link to one with comment access

Via @ewdurbin: per this tweet and this blog post,

On Friday October 30th at 11:15 AM EDT the Python Software Foundation will be live streaming a remote key generation and signing ceremony to bootstrap The Update Framework for The Python Package Index.

@jku has some related work people might want to give feedback on, in pip: https://github.com/pypa/pip/issues/8585 and https://github.com/pypa/pip/pull/9041 .

I see #7488 (comment) mentions a few blockers that people are currently working on ("some bugs in the TUF reference implementation, namely missing roledb state when reloading the repository").

theupdateframework/tuf#574

theupdateframework/tuf#1045

theupdateframework/tuf#1048

A few people are working on those, including @sechkova and @lukpueh and @trishankatdatadog. I'm sure they would welcome help.

I believe all of this is still true except that theupdateframework/tuf#1045 is closed.

I see #7488 (comment) mentions a few blockers that people are currently working on ("some bugs in the TUF reference implementation, namely missing roledb state when reloading the repository").

theupdateframework/tuf#574

theupdateframework/tuf#1045

theupdateframework/tuf#1048

A few people are working on those, including @sechkova and @lukpueh and @trishankatdatadog. I'm sure they would welcome help.

I believe all of this is still true except that theupdateframework/tuf#1045 is closed.

theupdateframework/tuf#1048

We addressed all of the blockers for Warehouse integration of TUF mentioned above. The remaining, recently filed, issue in TUF is the addition of an abstract signing interface to support the use of signing keys stored in Hashicorp Vault.
That work is being discussed in https://github.com/theupdateframework/tuf/issues/1263

theupdateframework/tuf#1048

We addressed all of the blockers for Warehouse integration of TUF mentioned above. The remaining, recently filed, issue in TUF is the addition of an abstract signing interface to support the use of signing keys stored in Hashicorp Vault.
That work is being discussed in https://github.com/theupdateframework/tuf/issues/1263

I'm having trouble following some of the twists and turns in the linked issues and pull requests, so please forgive my ignorance -- what is left in order to finalize TUF support on PyPI? Just theupdateframework/tuf#574 ?
(And then attention ought to move to pypa/pip#8585  to finish up the pip side, I believe.)

On the TUF side, abstract signer support is still needed. https://github.com/secure-systems-lab/securesystemslib/pull/319 added it to SSLib, but I don't believe that work's been integrated into TUF itself yet. Once it is, I'll be able to continue work on the various Vault interfaces that Warehouse will use to sign metadata.

On the TUF side, abstract signer support is still needed. secure-systems-lab/securesystemslib#319 added it to SSLib, but I don't believe that work's been integrated into TUF itself yet.

Correct, though there's a PR which I'm planning to review next week https://github.com/theupdateframework/tuf/pull/1272

It may not be necessary, but is there a milestone or a project board to collect the issues for this epic?
"Package signing & detection/verification" says "78%" complete, but milestones can't include issues from other repos?
https://github.com/pypa/warehouse/milestone/16
Project boards can reference issues from multiple repos.
https://github.com/pypa/warehouse/projects
It's not clear who would create and update a GH project board if even necessary for these issues

I think a project board would certainly help! I only have triage permissions on this repo, so @brainwane or someone else with more permissions might need to either grant me access or do it.

sorry, I don't have time to look into this - @ewdurbin could you see about giving Will project board permissions for this repo? Thanks.

Speaking of which, do we have updates about the integration? Have not heard updates in a while...
Cc @joshuagl @mnm678

Sorry for joining late at the party. I tried to understand how TUF compares to blockchain protection mechanisms against take over and tampering, and to me TUF claims seem misleading.
First TUF main page at https://theupdateframework.io/ claims it provides protection from repo take over.

The Update Framework (TUF) helps developers maintain the security of software update systems, providing protection even against attackers that compromise the repository or signing keys.

And then in https://theupdateframework.io/overview/#how-does-tuf-secure-updates it says this.

TUF identifies the updates, downloads them, and checks them against the metadata that it also downloads from the repository.

In the blockhain world that just means that whoever gains access to this central node, rehashes contents to be legit, and pwns clients, because clients don't even have a copy of Merkle Tree hash to check. How this TUF protection is supposed to work? Could someone explain it like I am five?
If the security of the whole specification is provided by offline keys and out-of-band keys distribution, then I don't see how that security can be realistically implemented. https://fwupd.org/ doesn't implement TUF, much more simple, and is secure enough to distribute firmware updates for hardware on Linux.

How this TUF protection is supposed to work? Could someone explain it
like I am five?

@Marina Moore @.***> has put together a helpful set of blog posts
( https://ssl.engineering.nyu.edu/blog/ ) that use Santa Claus and
Calvinball (from Calvin and Hobbes) as examples.  Let us know if this
helps.  :)

@JustinCappos I am afraid that a distraction for 5 years olds, not an explanation really. :D

In the blockhain world that means that attacker can rehash the content of the repo, and trick clients that the signed content is legit, because clients don't even a copy of Merkle Tree hash to validate the repo at any point in history. How TUF is protects from that? Could someone explain it like I am five?

TUF and blockchains are based on different threat models. A blockchain uses decentralized nodes so that an attacker would have to compromise a lot of these nodes to gain control. However, it's not always practical to have a network of trusted nodes for software distribution, and it takes a lot of computation to do the proof-of-work necessary to add new items to a blockchain. TUF instead takes the existing package manager approach, and uses offline keys, revocation, and pinned keys to ensure that a compromise of the repository can be detected and recovered from. Using the blockchain analogy, TUF uses pinned root keys instead of a Merkle Tree hash to validate the state of the repository. This has the advantage that the pinned root keys remain valid through updates to the repository.

If the security (by the spec) is provided by offline keys and out-of-band keys distribution, then I don't see how that security can be implemented, or if it worths the complication. For example, https://fwupd.org/ distributes firmware updates for hardware on Linux, is simple and secure without TUF. If analogy with the blockchain is hard, this can be used as an alternative baseline.

This model has already been mostly adopted by PyPI, as well as many others, so it is certainly possible to implement. @trishankatdatadog can provide more insight into deploying TUF in production.
I don't know the details about https://fwupd.org/ specifically, but numerous supply chain security compromises of production systems occur because of a repository or key compromise. TUF mitigates these risks through the use of offline keys, threshold delegations, and namespacing.

Also a blockchain doesn't deal with the problems of how do you figure out what to put on there and who can change it if it is wrong / stale / keys are compromised. TUF handles those cases.

I agree. I have no idea why TUF is being compared to a blockchain without the reader doing their due research.
If you must, see this article we wrote comparing a centralized "blockchain" (transparent/tamper-evident logs) to TUF, and why you probably want to use both.

@mnm678 first, thanks for the explanation. Some nerdy guys like me are completely senseless to people when it comes to "defending the truth". ) I try not to criticize, but when I fail, please forgive me.

However, it's not always practical to have a network of trusted nodes for software distribution,

That's an mistake no.1 (hope you don't mind the terminology, but I don't know another word). Nodes in blockchain are not trusted. They follow the consensus rules. Good nodes do not listen to those who do not follow the consensus. Validating the consensus in that every node does when receiving the block. This way you have near real-time sync of package info and threat detection.

and it takes a lot of computation to do the proof-of-work necessary to add new items to a blockchain.

Mistake no.2 (again I don don't blame anyone - it took me several years to separate blockchain technology from blockchain hype). Proof-of-work is a consensus algorithm for ledgers (accounting books) which designed to solve double spending problem. PyPI is not a ledger, so it is totally irrelevant here. Blockchain is a signed chain of signed blocks. In case of PyPI, one block can be just one package data. The agreement, who can add the blocks is the consensus. "Every user with an account in PyPI can add block" may be a valid rule. "Only blocks that are signed with offline keys" may be a valid rule (although this can be extended to "keys that are signed by offline keys"). "Only users who have the most balance" is not the valid rule for PyPI, but it is another consensus for public ledgers called proof-of-stake.

TUF instead takes the existing package manager approach, and uses offline keys, revocation, and pinned keys to ensure that a compromise of the repository can be detected and recovered from. Using the blockchain analogy, TUF uses pinned root keys instead of a Merkle Tree hash to validate the state of the repository. This has the advantage that the pinned root keys remain valid through updates to the repository.

How packagers sign their packages if TUF private keys are offline?
What are pinned keys? My 5 years old have just read from Wikipedia that public keys pinning for HTTP was considered deprecated, and my search query for pinned keys show a lot of articles that do not recommend this technique.
Unfortunately, without understanding if TUF pinned keys are similar to HTTP pinning keys, I can not comment on if they can really replace Merkle Tree in validating the current state of repository. The state in Merkle Tree not only covers specific package, it coverts the state of all packages at the moment it is generated. If the pinned key signs the state of repository, then it brings another question.
Who owns pinned keys? (package maintainer, PyPI admin, TUF admin)

This model has already been mostly adopted by PyPI, as well as many others, so it is certainly possible to implement.

This doesn't answer the original question  - how specifically to sign PyPI packages with offline keys, and which out-of-band channels PyPI users should use for keys distribution. A simple example for a monkey who wants to upload package to PyPI in the most secure manner would do.

I don't know the details about https://fwupd.org/ specifically, but numerous supply chain security compromises of production systems occur because of a repository or key compromise. TUF mitigates these risks through the use of offline keys, threshold delegations, and namespacing.

I haven't found https://fwupd.org/ in the list, so it is hard for to me to accept this argument against it. If TUF security is provided by offline keys, so does the https://fwupd.org/ but without the complications imposed by TUF. https://fwupd.org/ distributes packages signed/encrypted by vendor key (TUF offline keys), and BIOS and other hardware (according to UEFI spec) will not update itself if the signature doesn't match hardcoded public key (TUF out-of-band channel). So the security of TUF and https://fwupd.org/ are equivalent.

I haven't found https://fwupd.org/ in the list, so it is hard for to me
to accept this argument against it. If TUF security is provided by offline
keys, so does the https://fwupd.org/ but without the complications
imposed by TUF. https://fwupd.org/ distributes packages signed/encrypted
by vendor key (TUF offline keys), and BIOS and other hardware (according
to UEFI spec) will not update itself if the signature doesn't match
hardcoded public key (TUF out-of-band channel). So the security of TUF
and https://fwupd.org/ are equivalent.

From the https://fwupd.org/lvfs/docs/developers site under "Is updating
firmware secure?"
In both the LVFS and fwupd, GPG crypto is being performed using GnuPG and
PKCS#7 crypto is using GnuTLS. The fwupd daemon has no network access and
only acts as the mechanism for clients using D-DBus and PolicyKit. Some
devices also have additional hardware signature verification schemes
implemented by the device manufacturer.
The LVFS and fwupd codebases have had several independent security audits.
The LVFS has a huge number of tests run for each commit
https://travis-ci.org/hughsie/lvfs-website, and fwupd has a comprehensive
test suite https://travis-ci.org/hughsie/fwupd, and is regularly scanned
using both clang and Coverity https://scan.coverity.com/projects/10744.
The threat model implied here is that they sign something and are careful
with the key.  There is no talk about how they handle key revocation, etc.
TUF focuses on dealing with compromises.  Not only just keys, but of
servers and other parts of the infrastructure.  Of course, we've had audits
too (which you can find linked on the project site), but the system is
designed to resist and securely recover from a compromise of keys, servers,
etc. So the threat model and goals are very different.  (You can find a lot
more about TUF's goals by reading this page, especially the Mitigating Key
Risk portion https://theupdateframework.io/security/ )
The website also has a lot of technical papers that describe the security
differences in much greater detail over solutions that use a single key for
signing, such as the project you mentioned.
How packagers sign their packages if TUF private keys are offline?
There are different keys in TUF.  Some keys (like the root keys and some
targets keys) are offline.  Others are held by the developers.
To try to give the five year old version.  If you have a small project on
your own, you have your key for your project.  If you have a group project,
you can choose if one person has the key, if multiple people have to use
keys, etc.
Just so you're not confused about pinning, this isn't HTTP pinning.  The
reasons why HTTP pinning is deprecated don't make sense in this context
because you don't have hundreds of potentially valid roots of trust
(trusted CAs) and have to deal with the problems with having something
incorrectly pinned to the incorrect version.  PyPI's targets role handles
this namespacing unambiguously.
On Tue, Aug 31, 2021 at 11:02 PM Anatoli Babenia @.***>
wrote:

@mnm678 https://github.com/mnm678 first, thanks for the explanation.
Some nerdy guys like me are completely senseless to people when it comes to
"defending the truth". ) I try not to criticize, but when I fail, please
forgive me.
However, it's not always practical to have a network of trusted nodes for
software distribution,
That's an mistake no.1 (hope you don't mind the terminology, but I don't
know another word). Nodes in blockchain are not trusted. They follow the
consensus rules. Good nodes do not listen to those who do not follow the
consensus. Validating the consensus in that every node does when receiving
the block. This way you have near real-time sync of package info and threat
detection.
and it takes a lot of computation to do the proof-of-work necessary to add
new items to a blockchain.
Mistake no.2 (again I don don't blame anyone - it took me several years to
separate blockchain technology from blockchain hype). Proof-of-work is a
consensus algorithm for ledgers (accounting books) which designed to solve
double spending problem. PyPI is not a ledger, so it is totally irrelevant
here. Blockchain is a signed chain of signed blocks. In case of PyPI, one
block can be just one package data. The agreement, who can add the blocks
is the consensus. "Every user with an account in PyPI can add block" may be
a valid rule. "Only blocks that are signed with offline keys" may be a
valid rule (although this can be extended to "keys that are signed by
offline keys"). "Only users who have the most balance" is not the valid
rule for PyPI, but it is another consensus for public ledgers called
proof-of-stake.
TUF instead takes the existing package manager approach, and uses offline
keys, revocation, and pinned keys to ensure that a compromise of the
repository can be detected and recovered from. Using the blockchain
analogy, TUF uses pinned root keys instead of a Merkle Tree hash to
validate the state of the repository. This has the advantage that the
pinned root keys remain valid through updates to the repository.
How packagers sign their packages if TUF private keys are offline?
What are pinned keys? My 5 years old have just read from Wikipedia
https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning that public keys
pinning for HTTP was considered deprecated, and my search query for pinned
keys https://www.google.com/search?client=firefox-b-d&q=pinned+keys
show a lot of articles that do not recommend this technique.
Unfortunately, without understanding if TUF pinned keys are similar to
HTTP pinning keys, I can not comment on if they can really replace Merkle
Tree in validating the current state of repository. The state in Merkle
Tree not only covers specific package, it coverts the state of all packages
at the moment it is generated. If the pinned key signs the state of
repository, then it brings another question.
Who owns pinned keys? (package maintainer, PyPI admin, TUF admin)
This model has already been mostly adopted by PyPI, as well as many
others, so it is certainly possible to implement.
This doesn't answer the original question - how specifically to sign PyPI
packages with offline keys, and which out-of-band channels PyPI users
should use for keys distribution. A simple example for a monkey who wants
to upload package to PyPI in the most secure manner would do.
I don't know the details about https://fwupd.org/ specifically, but
numerous supply chain security compromises of production systems occur
because of a repository or key compromise. TUF mitigates these risks
through the use of offline keys, threshold delegations, and namespacing.
I haven't found https://fwupd.org/ in the list, so it is hard for to me
to accept this argument against it. If TUF security is provided by offline
keys, so does the https://fwupd.org/ but without the complications
imposed by TUF. https://fwupd.org/ distributes packages signed/encrypted
by vendor key (TUF offline keys), and BIOS and other hardware (according
to UEFI spec) will not update itself if the signature doesn't match
hardcoded public key (TUF out-of-band channel). So the security of TUF
and https://fwupd.org/ are equivalent.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/pypa/warehouse/issues/5247#issuecomment-909320283,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGRODZNNGUXZ645HQTIKALT7TVHBANCNFSM4GNHO6PQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

Also a blockchain doesn't deal with the problems of how do you figure out what to put on there and who can change it if it is wrong / stale / keys are compromised.  TUF handles those cases.

@JustinCappos that's a valid point, and a tough problem. if anyone can explain in those childish terms how the handling is done, that would clear up my doubts. Right now I understand this as if offline keys are lost, everything is lost. The same way if private key on the blockchain is lost. On the blockchain the problem is solved with multisignature keys, so that you need 3 out of 5 signatures to make multisig valid. There are also extensions that allow to migrate valid multisig to another multisig with no missing keys.

If you must, see this article we wrote comparing and contrasting a centralized "blockchain" (transparent/tamper-evident logs) to TUF, and why you probably want to use both.

@trishankatdatadog yes, I've read it (after asking), and I like TL very much. I think it is a way to go. So far it seemd that TUF adds a very high level of complexity even if TL + TUF is the most secure. It is hard to explain, unlike blockchain concepts, which many people have already learned. It also hard to me to wrap my head how the TUF absence of immutable history and third-party auditing can provide security in the world, where the state of dependency tree is often more important than the state of packages you own.
While I don't think that TUF is the way to go, I think it may have some good ideas on how to manage signing keys, so instead of following TUF or using combined TF+TUF, there may be a slimmed down version of security framework, that reuses components from both and also leverages some best practices from blockchain technology (like real-time sync, notifications and caching).

Hello @abitrolly! I appreciate your engagement and concern with the security of PyPI shown in this discussion.
However, there are multiple points in the recent conversation where you have chosen to belittle or dismiss things as "childish" and comparing efforts of those involved to 5 year olds. This isn't very respectful of the effort and time that people have put into this work.
I'd like to ask you to review the PSF Code of Conduct, which this repository and discussion adheres, before further disrespectful behavior becomes an issue.

While I don't think that TUF is the way to go, I think it may have some good ideas on how to manage signing keys, so instead of following TUF or using combined TF+TUF, there may be a slimmed down version of security framework, that reuses components from both and also leverages some best practices from blockchain technology (like real-time sync, notifications and caching).

Consider that if something looks complicated, there might be good reasons for it, especially if it was designed with a threat model with nation-state attackers in mind. Feel free to use TLs all you like, but the PyPA consensus has been for TUF, with the community free to record TUF metadata on TLs if they wish, thus getting the best of both worlds.

@ewdurbin all I wanted is to receive a layperson-friendly explanation as it happens in https://www.reddit.com/r/explainlikeimfive/ which I've subscribed to. I apologize that I haven't referenced it in the first place. Does that clarify that the phrase "explain me like I am five" is not done to belittle or dismiss things as "childish", or offend those who put many efforts in developing and promoting TUF?

I'd like to ask you to review the PSF Code of Conduct, which this repository and discussion adheres, before further disrespectful behavior becomes an issue.

I acknowledge time and effort that people put into developing TUF and trying to include it into Python distribution index. If the critics of TUF framework itself is seen as disrespectful behavior, then it will be better for me to leave the people to their business.

Thanks for your feedback.
IMHO, Sigstore should be (1) at least rooted in a trustless blockchain;
and (2) using ld-proofs and W3C Signature Suite URIs. That aside, how can
Sigstore and TUF work together?
Is there a good ELI5 graphic of the PyPI TUF package build and release
workflow, and maybe also a complete sequence diagram?
https://en.wikipedia.org/wiki/Sequence_diagram
![Sigstore architecture summary]
(https://www.sigstore.dev/img/system_architecture_summary-01.svg)
On Fri, Sep 3, 2021, 04:42 Anatoli Babenia @.***> wrote:

@ewdurbin https://github.com/ewdurbin all I wanted is to receive a
layperson-friendly explanation as it happens in
https://www.reddit.com/r/explainlikeimfive/ which I've subscribed to. I
apologize that I haven't referenced it in the first place. Does that
clarify that the phrase "explain me like I am five" is not done to belittle
or dismiss things as "childish", or offend those who put many efforts in
developing and promoting TUF?
I'd like to ask you to review the PSF Code of Conduct, which this
repository and discussion adheres, before further disrespectful behavior
becomes an issue.
I acknowledge time and effort that people put into developing TUF and
trying to include it into Python distribution index. If the critics of TUF
framework itself is seen as disrespectful behavior, then it will be better
for me to leave the people to their business.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/pypa/warehouse/issues/5247#issuecomment-912368404,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAMNSZ2CYOUPZMLY3R6GG3UACC6DANCNFSM4GNHO6PQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

Thanks for your feedback.
IMHO, Sigstore should be (1) at least rooted in a trustless blockchain; and (2) using ld-proofs and W3C Signature Suite URIs. That aside, how can Sigstore and TUF work together?
Is there a good ELI5 graphic of the PyPI TUF package build and release workflow, and maybe also a complete sequence diagram?
https://en.wikipedia.org/wiki/Sequence_diagram
https://www.sigstore.dev

In a rush, but quickly wanted to point out that Sigstore uses TUF...
https://dlorenc.medium.com/using-the-update-framework-in-sigstore-dc393cfe6b52
On Fri, Sep 3, 2021 at 11:32 PM Wes Turner @.***> wrote:

Thanks for your feedback.
IMHO, Sigstore should be (1) at least rooted in a trustless blockchain;
and (2) using ld-proofs and W3C Signature Suite URIs. That aside, how can
Sigstore and TUF work together?
Is there a good ELI5 graphic of the PyPI TUF package build and release
workflow, and maybe also a complete sequence diagram?
https://en.wikipedia.org/wiki/Sequence_diagram
![Sigstore architecture summary]
(https://www.sigstore.dev/img/system_architecture_summary-01.svg)
On Fri, Sep 3, 2021, 04:42 Anatoli Babenia @.***> wrote:

@ewdurbin https://github.com/ewdurbin all I wanted is to receive a
layperson-friendly explanation as it happens in
https://www.reddit.com/r/explainlikeimfive/ which I've subscribed to. I
apologize that I haven't referenced it in the first place. Does that
clarify that the phrase "explain me like I am five" is not done to
belittle
or dismiss things as "childish", or offend those who put many efforts in
developing and promoting TUF?
I'd like to ask you to review the PSF Code of Conduct, which this
repository and discussion adheres, before further disrespectful behavior
becomes an issue.
I acknowledge time and effort that people put into developing TUF and
trying to include it into Python distribution index. If the critics of
TUF
framework itself is seen as disrespectful behavior, then it will be
better
for me to leave the people to their business.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/pypa/warehouse/issues/5247#issuecomment-912368404,
or unsubscribe
<
https://github.com/notifications/unsubscribe-auth/AAAMNSZ2CYOUPZMLY3R6GG3UACC6DANCNFSM4GNHO6PQ
.
Triage notifications on the go with GitHub Mobile for iOS
<
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
<
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/pypa/warehouse/issues/5247#issuecomment-912624534,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGROD3S22WGH66XULSHY7DUADS7JANCNFSM4GNHO6PQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

IMHO, Sigstore should be (1) at least rooted in a trustless blockchain; and (2) using ld-proofs and W3C Signature Suite URIs. That aside, how can Sigstore and TUF work together?

I'm not: (1) sure that there is such a thing as "trustless" blockchain, and (2) familiar with these technologies. However, Marina and I wrote a blog post about how you can combine TUF and transparent/tamper-evident logs such as sigstore. TLDR: you can publish TUF timestamp metadata on sigstore. My upcoming talk at SupplyChainSecurityCon will discuss how the Datadog Agent integrations is the first transparent compromise-resilient software publication pipeline in the world.

Is there a good ELI5 graphic of the PyPI TUF package build and release workflow, and maybe also a complete sequence diagram?

I don't there is one right now, but perhaps you could help us make one using the descriptions from PEPs 458 and 480?

In a rush, but quickly wanted to point out that Sigstore uses TUF...

Yes. This will be a separate TUF repository for open source projects, distinct from the one for PyPI right now. However, PyPI can publish its own TUF timestamps to sigstore.

I'm not: (1) sure that there is such a thing as a "trustless" blockchain,

Some criteria for "trustless blockchains" (DLT Distributed Ledger Technology) in the Software Supply Chain [Security] domain:

Nobody has root.
Everyone has backup responsibilities, if they want.
Everyone can check that the online data matches the online backups.
Only users with package release permissions can create a new SoftwareRelease record for that project

Does this imply that a permissioned chain is necessary: wherein certain parties gatekeep which keys can sign for which package; is a permissioned chain necessary for Role Delegation / Authorization?

Otherwise, if a package author lost the initial package_name 'token' (?), e.g. PyPI would have no way to recover that initial key and the only option would be to change the package name: a DID-like package name could be "burnt" and thus unrecoverable. Does TUF have these risks, as well?

and (2) familiar with these technologies.

Do they implement the same primitives with different or "yet another" data representation standards?

https://w3c-ccg.github.io/ld-proofs/

Cryptographic proofs enable functionality that is extremely useful to implementors of distributed systems. For example, proofs can be used for purposes such as:

Make statements that can be shared without loss of trust, because their authorship can be verified by a third party, for example as part of Verifiable Credentials [VC-DATA-MODEL] or social media posts.
Authenticate as an entity identified by a particular identifier, for example, as the subject identified by a Decentralized Identifier (DID) [DID-CORE].
Delegate authorization for actions in a remote execution environment, via mechanisms such as
Authorization Capabilities [ZCAP].
Agree to contracts where the agreement can be verified by another party.
Additionally, many proofs that are based on cryptographic signatures provide the benefit of integrity protection, making documents and data tamper-evident.
The term Linked Data is used to describe a recommended best practice for exposing, sharing, and connecting information on the Web using standards, such as URLs, to identify things and their properties. When information is presented as Linked Data, other related information can be easily discovered and new information can be easily linked to it. Linked Data is extensible in a decentralized way, greatly reducing barriers to large scale integration.

With the increase in usage of Linked Data for a variety of applications, there is a need to be able to verify the authenticity and integrity of Linked Data documents. This specification adds authentication and integrity protection to linked data documents through the use of mathematical proofs without sacrificing Linked Data features such as extensibility and composability.

https://w3c-ccg.github.io/ld-proofs/#linked-data-signatures :

{
"@context": [
   {"title": "https://schema.org#title"},
   "https://w3id.org/security/suites/ed25519-2020/v1"
 ],
 "title": "Hello world!",
 "proof": {
   "type": "Ed25519Signature2020",
   "created": "2020-11-05T19:23:24Z",
   "verificationMethod": "https://ldi.example/issuer#z6MkjLrk3gKS2nnkeWcmcxiZPGskmesDpuwRBorgHxUXfxnG",
   "proofPurpose": "assertionMethod",
   "proofValue": "z4oey5q2M3XKaxup3tmzN4DRFTLVqpLMweBrSxMY2xHX5XTYVQeVbY8nQAVHMrXFkXJpmEcqdoDwLWxaqA3Q1geV6"
  }
}

From https://w3c-ccg.github.io/ld-proofs/#dfn-proof-algorithm :

Creating New Proof Types
A Linked Data Proof is designed to be easy to use by developers and therefore strives to minimize the amount of information one has to remember to generate a proof. Often, just the cryptographic suite name (e.g. Ed25519Signature2018) is required from developers to initiate the creation of a proof. These cryptographic suites are often created or reviewed by people that have the requisite cryptographic training to ensure that safe combinations of cryptographic primitives are used.
[...]
A complete example of a proof type is shown in the next example:

EXAMPLE 7
{
 "id": "https://w3id.org/security#Ed25519Signature2020",
 "type": "Ed25519VerificationKey2020",
 "canonicalizationAlgorithm": "https://w3id.org/security#URDNA2015",
 "digestAlgorithm": "https://www.ietf.org/assignments/jwa-parameters#SHA256",
 "signatureAlgorithm": "https://w3id.org/security#ed25519"
}

https://www.w3.org/TR/did-core/ :

Decentralized identifiers (DIDs) are a new type of identifier that enables verifiable, decentralized digital identity. A DID refers to any subject (e.g., a person, organization, thing, data model, abstract entity, etc.) as determined by the controller of the DID. In contrast to typical, federated identifiers, DIDs have been designed so that they may be decoupled from centralized registries, identity providers, and certificate authorities. Specifically, while other parties might be used to help enable the discovery of information related to a DID, the design enables the controller of a DID to prove control over it without requiring permission from any other party. DIDs are URIs that associate a DID subject with a DID document allowing trustable interactions associated with that subject.
Each DID document can express cryptographic material, verification methods, or services, which provide a set of mechanisms enabling a DID controller to prove control of the DID. Services enable trusted interactions associated with the DID subject. A DID might provide the means to return the DID subject itself, if the DID subject is an information resource such as a data model.

The Blockcerts service implements W3C ld-proofs, DIDs,
https://www.blockcerts.org/guide/ :

Blockcerts is an open standard for building apps that issue and verify blockchain-based official records. These may include certificates for civic records, academic credentials, professional licenses, workforce development, and more.
Blockcerts consists of open-source libraries, tools, and mobile apps enabling a decentralized, standards-based, recipient-centric ecosystem, enabling trustless verification through blockchain technologies.
Blockcerts uses and encourages consolidation on open standards. Blockcerts is committed to self-sovereign identity of all participants, and enabling recipient control of their claims through easy-to-use tools such as the certificate wallet (mobile app). Blockcerts is also committed to availability of credentials, without single points of failure.
These open-source repos may be utilized by other research projects and commercial developers. It contains components for creating, issuing, viewing, and verifying certificates across any blockchain. These components form all the parts needed for a complete ecosystem.

Nobody has root.

"Key generation and signing ceremony for PyPI [TUF]"
https://pyfound.blogspot.com/2020/10/key-generation-and-signing-ceremony-for.html

https://github.com/psf/psf-tuf-runbook

I've published a roadmap for the PEP 458 rollout in https://github.com/pypa/warehouse/issues/10672. Please note that this issue is for PEP 458-related development work only, and is not a place to discuss TUF alternatives, issues with TUF as a framework, or ask for explanations on how TUF works.


Condaification

@gregvonkuster what do you think about adding a bioblend test to travis that actually runs an imaging tool?

@bgruening sure!  I'll need some instructions for doing this, can you provide some direction?

@gregvonkuster please look at the script section: https://github.com/bgruening/docker-galaxy-imaging/blob/master/.travis.yml#L63
I guess if you have a small bioblend script that uploads a datasets and runs a tools or even a workflow on it you can execute this script in this section. You could to this as well for the Chip-Exo Flavour.

@bgruening Thanks for the info - is there a working example of this that I can take a look at?


[Bug] RayJob does not get deleted after finishing

Search before asking

[X] I searched the issues and found no similar issues.

KubeRay Component
ray-operator
What happened + What you expected to happen
I am using a Kubernetes cluster with k3s v1.25.8.
Installed the kuberay-operator v0.5.0 using the instructions here.
When trying to follow this guide, the cluster starts, the job get submitted, and finishes, however, the cluster does not get deleted at the end.

  Observed Generation:    2
  Ray Cluster Name:       rayjob-sample-raycluster-fnw9z
  Ray Cluster Status:
    Available Worker Replicas:  1
    Desired Worker Replicas:    1
    Endpoints:
      Client:        10001
      Dashboard:     8265
      Gcs - Server:  6379
      Metrics:       8080
      Serve:         8000
    Head:
      Pod IP:             <IP_ADDRESS>
      Service IP:         <IP_ADDRESS>
    Last Update Time:     2023-04-08T20:54:27Z
    Max Worker Replicas:  5
    Min Worker Replicas:  1
    Observed Generation:  1
    State:                ready
  Start Time:             2023-04-08T20:54:27Z
Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  Normal  Created    19m   rayjob-controller  Created cluster rayjob-sample-raycluster-fnw9z
  Normal  Submitted  19m   rayjob-controller  Submit Job rayjob-sample-p5sv7

Anything else
No response
Are you willing to submit a PR?

[ ] Yes I am willing to submit a PR!

cc @architkulkarni

Hi @sbakiu , does the issue still occur with shutdownAfterJobFinishes set to true? https://ray-project.github.io/kuberay/guidance/rayjob/#rayjob-configuration
By default it's false.  We can consider updating this default if it makes more sense

Hi @architkulkarni,
no, it does not occur with the shutdownAfterJobFinishes: true
Thanks


Is there a way to trigger contract "sending" or "receipt" events

I have mocked a transaction to a contract which seems to be working well, but I'm not sure how to trigger events like "sending" or "receipt". For example, in our app code something like:
        contract.methods.contractMethod(param).send()
            .on('sending', function () {
                // how to trigger this
            })
            .once('receipt', function (receipt) {
                // or this
            })

Thank you!

Hi Matt 👋
Usually those are only abstractions of actual transaction confirmations (simple javascript loops and intervals).
You need to confirm the mocked transaction in order to trigger those: see here
It actually also required a small patch to make it work with web3js (which I've added in v11.2.0).
I've also added a test dedicated to web3js contract interactions that can serve as an example in this case:
https://github.com/DePayFi/web3-mock/blob/main/tests/units/web3wallet/web3js-contracts.spec.js
Let me know if there is anything else.

Thank you for the help! When I call confirm on my mocked transaction it seems to open an alert in the web UI shown in Cypress, is this what the 11.2 patch was supposed to fix? Perhaps I'm not correctly on the latest version?

There is one thing I've noticed with web3js that transactions are not sent immediately. Hence in the example test I added a 1 second timeout before confirming it: see https://github.com/DePayFi/web3-mock/blob/main/tests/units/web3wallet/web3js-contracts.spec.js#L57
web3-mock does not trigger any alert dialogs, so maybe you're catching errors somewhere in your code and trigger an alert there?
Any errors in the cypress console?

Otherwise you can also add a console.log('SENDING worked') as first thing in your on('sending') and a console.log('RECEIPT worked') as first thing in your once('receipt') callback in your code to see if you even get there.

I think this has been solved – right?
Let me know if otherwise, or if you have any further feedback/questions @megamattron

Yes, thank you. We didn't end up using this particular feature but the other fixes were super helpful, thanks again!


Distribution <IP_ADDRESS> breaks compatibility with User Defined Variables

Read/writes for IO variables are being grouped per module, which doesn't work for UDVs with different datatypes.
FYI @jacobson3 , I will have to work on correcting this before making a new release in VIPM. I will work on a separate branch though, once you approve the pull-request I just made.

Hi AgomezNI,
I just update my DCAF application. I'm using scan engine and facing issue with my User defined variable. I have 3 I32 FPGA to Host and 1 Boolean Host to FPGA.
Do you have any easy workaround ?
I can easily change my boolean to i32 I think
Best regards

Hi @mxrmesulog,
Yes, that is the issue documented here. I would suggest you downgrade to the previous version available in VIPM which doesn't have this problem


[Feature Request] [hooks] input#value bindings with useState

From https://github.com/facebook/react/issues/18611 including dmytro-lymarenko's ideas
Summary
Many of the popular JavaScript frameworks support binding value to a HTMLInputElement
The purpose of value binding is to eliminate the need both the value and the onchange property.
I think, with the new useState syntax, it became possible to implement this in react with a nice syntax and no breaking changes.
Detailed design
function MyComponent() {
  const bind = useState('')
  const [value, setValue] = bind
  return (
    <input bind={bind} />
    // ...
  )
}

Alternatives
By introducing a new hook.
In my opinion, this is easier to learn.
const [value, bind] = useStateBind('')

{value}

<input bind={bind} />

What is the benefit of not passing the value? Seems like your introduce API complexity and possible confusion to save a very minimal amount of typing. You could always do something like this yourself with a custom hook
const useBinding = (defaultValue) => {
  const [value, onChange] = useState(defaultValue)

  return { value, onChange }
}

// ...

const bind = useBinding('')

{bind.value}

<input {...bind} />

Almost every website has some sort of forms. By using a bind, the code will be cleaner and more failsafe.
And I think that this is not that confusing, and it takes seconds to learn it.

But with jquence's suggestion to make a custom hook, you're not going to be writing that. You'll be writing this:
<input type="text" placeholder="Hello World" {...bind} />

...which actually happens to be shorter than the proposed syntax, without introducing new API or new concepts

api implies low-level things, what you offer ALREADY can be described by the available api.

It would be great if exist an small standard library with a set of the most necessary hooks.
It’s bad when there is no standard, and everyone implements by himself such commonly used things as two way binding.

Hi, thanks for your suggestion. RFCs should be submitted as pull requests, not issues. I will close this issue but feel free to resubmit in the PR format.


[Table] Filter column component

This PR enable passing a component to render below the table header

Filter components are specific for each column and set with the renderFilter attribute in columns definition:
columns: [
  { label: "Name", path: "name", renderFilter: <MUITextField type="text" label="type to filter" /> },
  { label: "Age", path: "age" },
],

Table component doesn't provide any filter logic and filters are hidden by default. To toggle visibility simply set showFilters prop to  <Table /> accordingly.
Warning:
When table has sticky header MUI set sticky position at cell level (see <HeadCell />).
If filters row is visible, we need to set sticky positioning to the whole table head in order to avoid tracking the actual height of the first header row (which can vary depending on table width and cell content length).
Since this changes apply only when filters are visible, backward compatibility should be preserved.
ref: https://github.com/melfore/mosaic/issues/273

Hi @alessandrotilli you can proceed with merge of this PR 👍

Hi @luciob , I've rebased the branch in order to solve conflicts

:tada: This PR is included in version 7.3.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Curtains loading circle won’t go away

When an automation moves the curtains position the loading circle in the accessory wont stop.
If I move the curtains manually everything works fine: the loading circle appears for a while until the curtains stops and then disappears.
But I noticed that on my morning automation where all my curtains fully open the home app just stays with the loading circles forever.

As you can see in the picture the first curtain accessory doesn’t have the loading circle: that’s because I tap it once to start closing and again to open to make it disappear. That’s the only work around I have. If I don’t do that all curtain accessories will get stucked with the loading icon forever.
Seems like the plugin isn’t updating the front end stop command or something.

Looks like something's stalling somewhere - do accessories come back as Not Responding too?
Can you send your config please.

No, the curtains keep responding and working but the loading circle won't go away until I move the curtain position.
Maybe this issue has something to do with the temp issue that was hanging homebridge... I'll try the latest version with the fix and see if it keeps happening.

@iandronowicz did you have any luck with the latest version?

Closing for now, I'll re-open if needed.


Redirects needed for Image Resizing docs

OLD                          NEW
/images/about                /images
/images/responsive           /images/responsive-images
/images/worker               /images/resizing-with-workers
/images/overlays             /images/drawing-overlays
/images/errors               /images/troubleshooting
/images/protected-origin/    /images/controlling-origin-access

See https://github.com/cloudflare/cloudflare-docs/commit/1f6f131d093305eda0c1e59bbccb08214b2cbe23
cc @dotjs

@signalnerve how can I add redirects myself?
@zaid

Navigate to https://developers.cloudflare.com/images/_redirects (behind Access)


[Bug] [Master] The retry task was submitted in advance will block other task

Search before asking

[X] I had searched in the issues and found no similar issues.

What happened
version 2.0.7
The retry task was submitted in advance will block other task, because it was not removed from readyToSubmitTaskQueue
What you expected to happen
should not block the submission of other tasks
How to reproduce
Node P1:

Node P2:

Node F1:

Node F2:

Normally, P2 should be executed immediately after P1 ends, but P2 does not execute until F1 waits for two minutes to retry.
There are task instances:

This is the log for master:
TASK_STATE_CHANGE executeStatus: SUCCESS task instance id: 84 process instance id: 41 context: null
[INFO] 2022-10-27 14:55:41.651 org.apache.dolphinscheduler.server.master.runner.WorkflowExecuteThread:[423] - work flow 41 task 84 state:SUCCESS
[INFO] 2022-10-27 14:55:41.691 org.apache.dolphinscheduler.server.master.runner.WorkflowExecuteThread:[1376] - add task to stand by list, task name:P2, task id:0, task code:7349842754880
[INFO] 2022-10-27 14:55:41.693 org.apache.dolphinscheduler.server.master.runner.WorkflowExecuteThread:[1484] - task name: F1 retry waiting has not exceeded the interval time, and skip submission this time, task id:85
[INFO] 2022-10-27 14:55:41.695 org.apache.dolphinscheduler.server.master.runner.WorkflowExecuteThread:[1484] - task name: F1 retry waiting has not exceeded the interval time, and skip submission this time, task id:85
[INFO] 2022-10-27 14:57:35.661 org.apache.dolphinscheduler.server.master.runner.EventExecuteService:[127] - handle process instance : 41 , events count:1
[INFO] 2022-10-27 14:57:35.665 org.apache.dolphinscheduler.server.master.runner.EventExecuteService:[130] - already exists handler process size:0

Anything else
No response
Version
2.0.x
Are you willing to submit PR?

[ ] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Hi @JinyLeeChina, please take a look #12291

OK, let me test it


[feature request] Please support setuid

Currently Golang isn't capable of setuid and requests like this FreeBSD bug report can't be honored. See also this discussion about the same issue.

Can you be specific as to what is missing?  Neither link explains it, at least not to me.
On both FreeBSD and Linux systems syscall.Setuid should work fine.  (On Linux it has worked since the Go 1.16 release, on FreeBSD it worked all along).

Somebody claimed that setuid isn't possible from Golang, but they were apparently wrong.
Thank you for your help.


[BUG] Wemos D1 Mini ESP32 Reboots (Crashes?) on commands

I am using the Wemos D1 Mini ESP32 and have a curtain as well as a bot. Both exhibit similar behavior where they will have a new state set, update correctly, and then I can see on my router it disconnects and then reconnects. The MQTT state is then changed back to what it was before. If I check in HA I can see it update to the correct state, become unavailable, and then come back as the state before.

It happens almost every time, but has been successful a couple times in the past. I am unsure what is causing the issue, the is less than 10 feet away from both devices so it shouldn't be a connection issue.

can't say I have those issues.
watch the mqtt messages on switchbot/esp32 and switchbot/esp32/#
you will see what the esp32 is doing based on the mqtt messages.
If you see a "boot" message the esp32 rebooted.
make sure that no mqtt messages are retained on the 'set' topics or any topic that controls devices

@devWaves Thanks! I am trying to figure out mqtt explorer but I was able to find this which seems to confirm what I thought:

This is my config, I have not changed any advanced settings
/* Wifi Settings */
static const char* host = "switchbotController";                          //  Unique name for ESP32. The name detected by your router and MQTT. If you are using more then 1 ESPs to control different switchbots be sure to use unique hostnames. Host is the MQTT Client name and is used in MQTT topics
static const char* ssid = "REDACTED";                           //  WIFI SSID
static const char* password = "REDACTED";                   //  WIFI Password

/* MQTT Settings */
/* MQTT Client name is set to WIFI host from Wifi Settings*/
static const char* mqtt_host = "<IP_ADDRESS>";                       //  MQTT Broker server ip
static const char* mqtt_user = "REDACTED";                         //  MQTT Broker username. If empty or NULL, no authentication will be used
static const char* mqtt_pass = "REDACED";                         //  MQTT Broker password
static const int mqtt_port = 1883;                                  //  MQTT Port
static const std::string mqtt_main_topic = "switchbot";             //  MQTT main topic

/* Switchbot Bot Settings */
static std::map<std::string, std::string> allBots = {
  { "ice_maker", "f3:0f:e2:64:28:00" }
};

/* Switchbot Curtain Settings */
static const int curtainClosedPosition = 10;    // When 2 curtains are controlled (left -> right and right -> left) it's possible one of the curtains pushes one of the switchbots more open. Change this value to set a position where a curtain is still considered closed
static std::map<std::string, std::string> allCurtains = {
  { "back_door_curtain", "c4:0d:4d:58:c6:66" }
};

/* Switchbot Meter Settings */
static std::map<std::string, std::string> allMeters = {
  /*{ "meterone", "xX:xX:xX:xX:xX:xX" },
    { "metertwo", "yY:yY:yY:yY:yY:yY" }*/
};

/* Switchbot Contact Sensor Settings */
static std::map<std::string, std::string> allContactSensors = {
  /*{ "contactone", "xX:xX:xX:xX:xX:xX" },
    { "contacttwo", "yY:yY:yY:yY:yY:yY" }*/
};

/* Switchbot Motion Sensor Settings */
static std::map<std::string, std::string> allMotionSensors = {
  /*{ "motionone", "xX:xX:xX:xX:xX:xX" },
    { "motiontwo", "yY:yY:yY:yY:yY:yY" }*/
};

/* Switchbot Bot Passwords */
static std::map<std::string, std::string> allPasswords = {     // Set all the bot passwords (setup in app first). Ignore if passwords are not used
  /*{ "switchbotone", "switchbotonePassword" },
    { "switchbottwo", "switchbottwoPassword" }*/
};

/* Switchbot Bot Device Types - OPTIONAL */
/* Options include: "switch", "light", "button" */
static std::map<std::string, std::string> allBotTypes = {     // OPTIONAL - (DEFAULTS to "switch" if bot is not in list) - Will create HA entities for device types
 /* { "switchbotone", "switch" },
    { "switchbottwo", "light" },
    { "switchbotthree", "button" }*/
};

      /*** Bots in PRESS mode to simulate ON/OFF - ESP32 will try to keep track of the ON/OFF state of your device while in PRESS mode***/
      // Add bots while in PRESS mode that will simulate ON/OFF. Default state will be used if no MQTT retained on state topic
      // false = default state = OFF
      // true = default state = ON
      // If the state is incorrect, call set STATEOFF or STATEON
      static std::map<std::string, bool> botsSimulateONOFFinPRESSmode = {
        { "ice_maker", true }
      };

      //Add bots OFF hold time for simulated ON/OFF, if not in list, the current hold value will be used. Device must be in botsSimulateONOFFinPRESSmode list
      static std::map<std::string, int> botsSimulatedOFFHoldTimes = {
        /*{ "switchbotone", 0 },
          { "switchbottwo", 10 }*/
      };

      //Add bots ON hold time for simulated ON/OFF, if not in list, the current hold value will be used. Device must be in botsSimulateONOFFinPRESSmode list
      static std::map<std::string, int> botsSimulatedONHoldTimes = {
        /*{ "switchbotone", 15 },
          { "switchbottwo", 1}*/
      };
      /********************************************/

your config seems in order so not sure what the issue is
So you are using the bot with a device that doesn't have an ON/OFF correct? like a toggle button on a coffee maker or air conditioner ? otherwise you don't need botsSimulateONOFFinPRESSmode
You need to calibrate curtains with switchbot app first if you haven't. You should see a curtain topic like your bot
I can tell your bot doesn't have a password because you got the firmware value
if you see the "boot" message a lot then there is an issue somewhere with your setup that it doesn't like. You should see "boot" once when the esp32 turns on
if you only have curtain and bot you should see the blue LED on the esp32 turn off at least 2 min after booting. If it runs the full 2min it probably didn't find a device. The LED should turn off after boot once it finds all your devices. The LED will turn back on while controlling or scanning for devices.

Answers
I am using the bot with an ice maker which does have a single button to toggle on / off.
I do see a curtain topic and have calibrated them.
I see the "boot" message come up like I posted above quite often after sending the push command to switchbot or the open/close command to the curtain.
I unplugged and replugged the esp32 and the blue stays on for 5-10 secs so it seems to be finding the devices quite quickly.
Questions
Trying to think of what the issue could be since it does happen to the bot and the curtain (although much more often with the bot)

maybe try with the default names or shorter names. esp32, switchbotone, curtainone. If you said issues started with curtain, your curtain name is on the longer side
are you using Home Assistant? or manually sending commands?
maybe a simple reflash will fix it. Nothing stands out as an issue atm

@devWaves I am only using it with Home Assistant, did try a few reflashes to no avail. I tried shortening the names (to "ice" and "bd") and that seems to have done it. Very interesting that the length affected it.
I added a PR #52 to add a troubleshooting section to the README, let me know what you think.

So I tried with "ice_makerXXXXXXXXXXXXXXXXX" and "back_door_curtainXXXXXXXXXX" with ice_makerXXXXXXXXXXXXXXXXX in simulated on/off mode
I had zero issues. Works for me, so there must have been something else

Huh fair enough, it's been absolutely solid since so maybe I just had an unlucky few flashes and the last one I did fixed something.


How to generate same address with TrustWallet?

I'm trying to get address by fromMnemonic, while the address is different with the one generated in TrustWallet using the same mnemonic.
Is there a way to generate same address with TrustWallet by this great package? Thanks!
https://github.com/moneytrackio/tezart/blob/main/example/example.dart#L28-L35
final keystore = Keystore.fromMnemonic(mnemonic);
print(keystore.address);

I don't know how TrustWallet generates Tezos private keys from mnemonics. Nevertheless Keystore.fromMnemonic  has two optionnal parameters email and password you may use to change the key computed.
Is TrustWallet asking for credentials? if so, you may try to use them as email and password.

I don't know how TrustWallet generates Tezos private keys from mnemonics. Nevertheless Keystore.fromMnemonic has two optionnal parameters email and password you may use to change the key computed.
Is TrustWallet asking for credentials? if so, you may try to use them as email and password.

It seems that the address generation is not affected by the password in TrustWallet. I researched more wallets, such as imToken and Temple, they all generate same address when use same mnemonic.
Here is the way Temple use:
https://github.com/madfish-solutions/templewallet-extension/blob/2465deca4c/src/lib/temple/back/vault.ts#L329-L345

Kukai, Trust, and Spire all generate the same addresses (and different than tezarts')

I'm facing the same problem. Is tezart using a different derivation path than trust wallet?


Application Icon is Missing for App Execution Aliases (i.e. Run Commands)

Microsoft PowerToys version
0.61.1
Running as admin

[ ] Yes

Area(s) with issue?
PowerToys Run
Steps to reproduce

Ensure Microsoft Terminal is installed.
In Windows Settings -> Apps -> Advanced app settings -> App execution aliases, ensure the alias "wt.exe" is enabled for Terminal.
Start PowerToys Run (Win + Space)
Search for "wt" (the execution alias of terminal)

✔ Expected Behavior
The "wt" execution alias is shown, with the Terminal icon.
❌ Actual Behavior
The "wt" execution alias is shown, but with the default windows application icon.
Other Software
No response

This is similar to issue #16387 but refers to the App execution alias of the package, rather than the package itself.

Although I have not had a complete discussion on this issue, I have raised a Draft PR which demonstrates a proposed resolution. #20358

This has been resolved by #20358


Govcloud US-West Support?

What would you like to be added?
Hello,
Apologies if this is the wrong forum. I'm looking forward to working through the workshop. I only have access to an AWS account on govcloud. I have not looked at the terraform or other scripts/commands. Will I be able to work through all of the modules by just substituting the correct region, or should I expect that some aspects of the workshop won't work because features are not available in Govcloud?
Thanks for any help or advice before I begin.
Why is this needed?
Unsure whether GovCloud is supported.

GovCloud is not being tested. Please open an issue if something specific does not work in this environment.


Update dashboard to design v122 (Part 1)

Pull Request Description

Close #9886

Update style of buttons in Drive Bar
Move "Home" page into a "Start" dialog
Remove icons that are no longer needed
Remove Backend Switcher in top bar - they have now been converted to categories

Incidental changes

Refactor Backend provider so that both Remote and Local backends are available.

This was done because both Cloud and Local backends are now easily accessible by switching tabs - the Local backend no longer has its own views with the hidden category switcher

Important Notes
None
Code review tips

There are a lot of changes in Settings components, for example (and in general, any component that needs to use a backend). However, most of the changes are identical, so only the approach needs to be reviewed - although the settings pages and the other pages should probably be reviewed separately.

Testing instructions

Make sure new/changed features work, as mentioned above (drive bar, start page, drag-n-drop)
Because of the backend changes, all flows in general should be checked, at least at a basic level:

Sign up/sign in
Offline mode (bottom link on login screen on desktop app)
Checking that all settings pages work, both when logged in and not logged in

Screencasts
https://github.com/enso-org/enso/assets/4046547/d8f385e2-3355-404f-a346-035917d40cf9
Checklist
Please ensure that the following checklist has been satisfied before submitting the PR:

[x] The documentation has been updated, if necessary.
[x] Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
[x] All code follows the
Scala,
Java,
TypeScript,
and
Rust
style guides. In case you are using a language not listed above, follow the Rust style guide.
[x] Unit tests have been written where possible.

I guess I'll avoid stacking the move to tabs on top of this PR, as this is a big PR so there may be a lot of changes needed.

This loader is barely moving when running cloud project

After cmd+r when having project open in progress I no longer see calls projects/<project_id> so I had to reload again to gain access to opened project

This loader is barely moving when running cloud project

weird, i seem to be able to reproduce on develop. seems like it might be a regression

After cmd+r when having project open in progress I no longer see calls projects/<project_id>

ah. i guess we should store the "currently open project" immediately when the user clicks play, rather than after it actually opens. it's late though so probably won't be fixed today (and possibly will fix on the tabs PR instead.)

@somebody1234 could you please rebase onto latest changes so I can review them?

@MrFlashAccount latest changes pulled.

QA ⛔

Can we improve the drag experience to look similar to Google Drive? Currently, if user have a lot of assets, the DND button is hidden.
https://github.com/enso-org/enso/assets/61194245/066d2aa7-cbfe-415f-88ac-2e8b4738fa43
Invitations disappeared in settings
Buttons are not aligned (use ariaComponents.Button)

re: 3 - most style issues were fixed in the second PR. i figured it's easier to implement it once rather than having to backport. thoughts?

2 & 3. should be addressed.

seems like it's a bigger feature, but hopefully it's the last thing to address (after some other final refactors)

on second thought 1 will be left for later

After clicking Start with a template and closing modal I end up with this

New empty project and polling for status is bugged

Should this be so weird

Tooltips problem
https://github.com/enso-org/enso/assets/2855109/db6802ae-ded6-4b8d-b7ec-f5a96985ae9c

Show secret value is not aligned and doesn't work

Share with modal

Have we disabled cmd / shift + arrows multiple selection?

uhoh

fixed some things locally, some of them are still TODO:

fixed, assuming the issue is the focus ring being cut off

i've noticed the focus ring is inconsistent (spacing, animations) - this should probably be fixed at some point as well

TODO
fixed
fixed, assuming the issue is the positioning causing issues
fixed
fixed
(debugging TODO) idts - but it seems to be bugged, i can see the selection flashing for a moment before being reset to just the one row

@somebody1234 we can fix 7th on separate PR and then just fix 2nd issue here. Then we can push this to merge after all others are fixed

@MrFlashAccount just a note that this PR is blocked on your re-review

QA passed. I created one small fix https://github.com/enso-org/cloud-v2/issues/1301
lets fix the merge conflict and try to merge it today
@MrFlashAccount can you rereview and approve?


initOnClick should insert cursor at mouse click location, as default Froala editor does

If you view the froala example documentation, clicking on the "z" in "initialize" will initialise the editor, focus the editor and place the cursor after the 'z' character.
On the other hand, if you visit Ember Froala' s hide-on-blur and click anywhere on "Click here for an example", the editor isn't focused immediately and it requires a second click. This also ruins the user experience for hide-on-blur, as the editor only successfully hides if the user does perform the second click.

Humm... there does seem to be a disconnect somewhere in there. I'm unsure what could be causing that since initOnClick is a froala editor option and isn't "used" anywhere in the ember component.
Personally, I've moved away from the initOnClick and hide-on-blur solution because of general bugginess and a data-loss bug that bit me in the...
I'll do some digging. It looks like there might be some froala editor GitHub issues that might relate here.

Personally, I've moved away from the initOnClick and hide-on-blur solution because of general bugginess and a data-loss bug that bit me in the...

I'd be interested in the particulars - it seems like the perfect solution for my company's internal document generation application!

Yeah, it's a cool "feature" to only show the editing tools when needed. The specific related issues are;
froala/ember-froala-editor#19
froala/wysiwyg-editor#1586
froala/wysiwyg-editor#1504
All of those have since been fixed.

FYI, I'm trying to setup an ember-twiddle so we can play around with different scenarios, but there is an issue with twiddle's build process for addons that specify environment specific assets.
Also updated the froala-editor version to 2.4.1 and still experiencing this issue on the docs Website. Just not sure where the issue lies just yet.

FYI, figured out the problem. Setting the "html" on the init hook basically negates the focus and mucks some stuff up. I'll dig in to figure out what's needed to fix it.
https://github.com/froala/ember-froala-editor/blob/v2.4.2/addon/components/froala-editor.js#L311