Addressing Ownership and Identity for packages at entry into FAIR

[ramseyp]

This writing is attempting to address a security challenge in the FAIR protocol as it appears to be written: how to verify package authors' identities before allowing code into the federated distribution system. The core problem is preventing malicious actors from impersonating legitimate developers and distributing code (malicious or otherwise) under false identities. The best solution appears to be a two-phase approach combined with clear communication to the public about ownership. @toderash and I set out to tackle this and bring it to the group. Yes, it's long, but we've tried to lay out the ownership and identity issues in a design perspective, not technical, necessarily.

Short-term, the suggestion is to leverage WordPress.org's existing "manual" verification process by mirroring packages from dot-org and inheriting their established trust relationships. DIDs are added to serve as a second layer of verification.

Long-term, we envision both a centralized “FAIR Labeling Server" (below, under the “Centralized Authorship Verification Design” heading) that serves as the authoritative source for package identity verification and a manual registration process that feeds into this server. In both the short and long-term, no package enters the federated system without proper identity validation combined with a DID. In the perfect world, dot-org joins FAIR and can continue serving as the registration source for package authors - the question will remain for those who never publish on dot-org, but if the landscape changes for WordPress, this may be addressed outside of this writing.

The writing calls out some more granular situations and technical challenges, including handling packages from sources other than WordPress.org, managing transitions when authors migrate from dot-org to federated systems, and the limitations of domain-based verification methods. We’re attempting to boil this down for clarity while remaining verbose enough to cover the needs we’re seeing that need to be addressed.

What is the need?

Within the FAIR protocol, the vexing question is this: How does FAIR address verifying someone is who they say they are? The scenario is one where a person fakes the ownership of someone else’s code. There is a moderation process and framework being put into place, including a dispute resolution process, but this would come *after* a bad actor has been identified, not how to prevent a bad actor from coming into the system. With FAIR being a federated distributed system, the onus lies in preventing a fake identity from getting in and being distributed. The use of DIDs and associating them with something like a domain, implies trust that both the code and the domain are legit. Both a domain and code can be hijacked or compromised.

Therein lies the need. How is a plugin owner/theme owner “verified” today? Dot-org handles this in the submission process: Planning, Submitting, and Maintaining Plugins – Plugin Handbook | Developer.WordPress.org. This is a “human” process that doesn’t readily have a technical solution. As an author goes through the registration and verification process, “trust” is established. FAIR needs this piece of the equation. If FAIR wants hosts and others to participate and add a node to the network, FAIR is asking them to trust the package coming into those nodes and inherit the risk and responsibility to their customers. This “trust” carries immense risk without a defined way of establishing identity and ownership prior to packages hitting the federated distribution. Businesses and groups will not assume that risk nor should they be asked to.

Short term: Mirroring dot-org

For the near-term, with AspireCloud being the practical example, by using dot-org as the source for packages coming into AspireCloud, ownership & identity for FAIR can be inherited from dot-org. Dot-org has an established registration/validation/verification process (Planning, Submitting, and Maintaining Plugins – Plugin Handbook | Developer.WordPress.org) giving any code mirrored from there an “owner”. Once AspireCloud brings in the code, a DID can be associated with a package, giving two pieces of identity. An evolution of this process would involve instructions to package authors to add a DID to their code. FAIR can recognize this addition, combined with coming from dot-org as a “double method” way of establishing identity.

Moving from dot-org to FAIR, or laying out an outline

Initially, we are operating heavily on the Assumption or Dependency that: An author has a published package on dot-org. As such, dot-org serves as the initial “trust” source for ownership, meaning we trust someone is who they say they are if they have published code on dot-org. Under this assumption:

• Packages from dot-org are mirrored.
  • Ownership is inherited from dot-org
  • A working DID is assigned
    • This is a point requiring clear communication - the working DID is intended to be temporary, until a package author is able to establish their own, at which time their DID becomes “canonical”. Ownership of an author’s package belongs to the author, not FAIR.
  • A label is added to the package establishing ownership verification: “author established” (Centralized Authorship Verification Design heading below)
  • The package is formatted to the FAIR spec, ready for distribution / federation

When a developer adds their own DID to a package that is hosted on dot-org, which we propose authors start doing:

• Packages from dot-org are mirrored
  • AspireSync scans package from dot-org for introduction of DID, establishing identity of the author as connected to the new DID
  • No working DID is applied via AspireSync
• If DID is found, AspireSync will:
  • Resolve the DID to verify the listing exists and the required meta is present in the declared repo
    • Currently the Bluesky PLC server is the only source for DID resolution
    • Must validate that the package with the new DID & source repo complies with the minimum FAIR protocol requirements
  • Update AC to index the plugin from its FAIR repo source
  • Update AC to de-list it from the dot-org mirror
  • Cancel the working DID using the tombstone process
    • Cancelling the working DID is better than transferring it to the package owner as an alias since it essentially undoes that interim DID (working DID), removing any implied ownership package authors may be worried about (and which clear communication on package ownership would address)
• Result: continuity from dot-org to FAIR with same package maintainer(s)

When a developer has a package hosted on dot-org, but then published only to FAIR (an issue highlighted below:

• A de-duplication process of ownership (and DIDs) is needed here to establish which one takes precedence. One would assume FAIR becomes the authoritative source. This is something to be worked out in a medium-term timeline. Note this is not the same as the technical issue of deduplication of packages, which has been resolved with a naming convention.

Two potential issues to consider:

• Dot-org could strip DID info, requiring a new process
  • If dot-org for some reasons decides to strip DIDs from packages published there, this accelerates FAIR needing a registration process that feeds into a labeling process that adds an “author established” label to packages.
• Package forks with same slug but different updates between dot-org & federated version (ACF to SCF) - rely on a deduplication process. If authors publish to both dot-org and then later publish only to FAIR, you have two sources of the same code. In a “transition scenario” such as this, some kind of de-duplication process is needed to prevent conflicts.

Thinking through newly-issued DIDs for Other-Than dot-org Sources

Risk Issues with Current Proposed Solution

Relying on verification of identity via a Txt record in DNS:

• Does not establish identity to a person (whois can be redacted). How does FAIR catch that the domain I use is mine? It appears to solely look for the record’s existence.
• Domain registration can be done with a throwaway email address & not renewed, leaving trust established falsely, but accepted by the verification process.

As such, without a registration / verification process, no process is clearly established for verifying someone is who they claim prior to their code being allowed in the system
Moderation - current proposed approach
Moderation PR: #14
In short, this appears to be an “after the fact” process - a way to report something after it’s in the system, as a package inherently can’t be labeled before it exists in the federated system.. It does not address the entry of a package into the system.

Considerations in New Proposed Approach

Must label as trusted in required FAIR service; see diagram in #35 - this requires a gate to establish trust.

• From a trust-established repo
  • Discuss whether a package with a new DID can/should inherit trust from a vetted repo
    • It feels like this can be a deferred decision on how to handle it in a systematic way. Shorter-term, a case-by-case “manual” process should suffice.
• From a new repo
  • Currently the verification & approval process will be manual
  • Alternative potential verification methods to be explored in the future might include:
    • DNS txt record IF the site also has an SSL/TLS certificate of the OV, IV, or EV type. (Organization Validation, Individual Validation, or Extended Validation, which tie the cert to a verified identity)
    • Third-party providers like Interac Verified
    • Other Public key certificate that includes identity verification as well as key pair validation
    • OAuth providers if they have verified identity (your bank has done so, Facebook and Github have not).
  • Submitted DIDs for packages will not be accepted for federation without identity verification to establish ownership or v of the package material.

Centralized Authorship Verification design

This issue moves in the right direction and shows a system that handles the authorship labeling for packages. This is additional to the DID and that’s needed as anyone getting a DID appears to be able to do so with no “prove you are who you say you are” process.

#35
The FAIR Moderation (Labeling) Server from the original diagram is necessary to keep the moderation system intact by providing trust signals. I'm proposing that FAIR operate one that is required for Aggregators and only provides the necessary trust signals.

In this diagram, the yellow node surrounded by a red box, labeled “Required: FAIR Labeling (Moderation) Server is a single, centralized authority for verifying identity & ownership of a package. It contains the source of truth for package identity in some kind of centralized list. No package is federated / distributed without being checked against this system.

Short(er) term, packages mirrored from dot-org carry the trust established by being published on dot-org, creating the initial list on the FAIR Labeling Server, and the package meta contains an “authorized/validated/verified” kind of label. This label only comes from this server.

Issue - the protocol as currently written looks to the Bluesky PLC server for the identities of packages. This doesn’t carry the trust needed. A package registered there (Bluesky server) has no identity verification against a source of truth, the dot-org packages, in the case above. How are we connecting/reconciling these two?

The Bluesky DID server may not be the right answer - we may need the “FAIR Labeling Server” to serve that role for a sense of trust and security or at least provide the “authority” label which is combined with the DID. No package is distributed without both.

What about packages not on dot-org

How does Crowd Favorite / PMPro / Gravity Forms / or other plugin authors not on dot-org prove identity? Anyone can register a DID, but the “authorized” identity label is missing. This scenario requires some kind of manual review process for these authors.

Questions to be addressed & some points carried over from the 31 July 2025 TSC call:

1. When an author removes a plugin from dot-org, how to clearly communicate ownership and identity with the author? Noted - clarity around ownership must be written up for the community
2. Author adds their own DID to package, does Aspire Cloud’s DID supersede it or will the author’s DID take precedence? How would it take precedence? The direction is that the Author’s DID takes precedence. The Aspire Cloud DID is internal/temporary and does not presume ownership.
3. It’s important that items like imported WordPress plugins are officially documented and that process isn't just in code, and along with this, additional policy docs are in place (not just github issues). As a start:
   1. Ownership of packages
   2. How self-hosted repos are approved as sources for packages published to FAIR
   3. Mirroring of dot-org packages
   4. De-duplicating packages when an author begins publishing to FAIR and they have code already on dot-org
   5. Glossary of terms: Moderation, Labeling, DID, Ownership, Package, etc.
   6. Our DID registration does not imply or assert ownership, it’s just transitional

[Ipstenu]

Moderation PR: #14
In short, this appears to be an “after the fact” process - a way to report something after it’s in the system, as a package inherently can’t be labeled before it exists in the federated system.. It does not address the entry of a package into the system.

Actually moderation can work on entry. It can run after the fact but as we are running a closed system at the start, we have the ability to flag and approve manually as it comes in.

Every single package is going to be added manually, or automatically from .org. Auto from org gets flagged as truth by our ApsireCloud repo.

But in no way is it going to be Jo Schmoe from Random Website submitting and having approved/added without a human looking.

Instead of looking at the code, we check that you're who you claim you are.

So don't write that off yet 😁

[toderash]

moderation can work on entry.

Thanks for catching / clarifying that. I understood this to be possible, but since I don't recall it explicitly being stated that it will be set up this way, the assumption couldn't be made. I suggest we state explicitly that the labeller for trust signals will be placed before federation occurs, in which case the label essentially blocks publication at all. The nomenclature implies that it goes out with the label attached, to be processed accordingly by the recipient. In some cases, we need to block before that happens.

In order to ensure we work toward something scaleable, I think we need to keep the discussion open, even if we deploy the required labeller in this fashion. Not only could we come up with certain automate-able steps that could be acceptable, but the discussion will help reveal the specific criteria that must be established. I know, I know, most of it is on the mod spec already; this would be about vetting & ratifying that list.

Until we do that, the answer might be, "Well, @Ipstenu reviews everything personally, and if she doesn't know you...." :P

[afragen]

• Packages from dot-org are mirrored.
  • Ownership is inherited from dot-org
  • A working DID is assigned
    • This is a point requiring clear communication - the working DID is intended to be temporary, until a package author is able to establish their own, at which time their DID becomes “canonical”. Ownership of an author’s package belongs to the author, not FAIR.
  • A label is added to the package establishing ownership verification: “author established” (Centralized Authorship Verification Design heading below)
  • The package is formatted to the FAIR spec, ready for distribution / federation

Perhaps using a Web DID like did:web:https://wordpress.org/plugins/plugin-slug would be easier to use and more clearly indicate that the package is from the dot org repository.

[jazzsequence]

the question will remain for those who never publish on dot-org, but if the landscape changes for WordPress, this may be addressed outside of this writing.

I'm actually more interested in this point. Inherit trust from .org is fine for plugin/theme authors who publish their code on .org. For authors who have removed their packages from .org already (or intend to), or no longer maintain their code on .org and are already today distributing updates outside of .org, there's a greater need to prioritize serving them over the FAIR protocol than .org, IMO. The landscape has already changed. Developers have already started doing this.

Currently the verification & approval process will be manual

Who or what is the (manual) verification/approval process? Who watches the watchers? If it's automated, what does that system look like? If it's a team of humans, how are the humans determined?

[chuckadams]

What we need in fairly short order is a way to express the trust relationships that already exist now, as machine-readable metadata. Right now we have the implicit trust in an upstream distributor (mainly .org) and the informal trust of individuals who are publishing packages (e.g. Andy and GU). We can work on formalizing the trust-granting mechanism through automated scanning, signoffs from reviewers, etc, but it would be a big step forward to communicate and authenticate the trust relationships that already exist now, in a way that lets a repo or aggregator make a "publish / don't publish" decision.

To me this sounds like a mechanism of machine-readable policies, with an eye toward Attribute Based Access Control (ABAC). There's a lot of prior art in this field, from the old Orange Book to modern zero-trust stacks. We don't need to dive into those too deeply to start, we just need to apply the idea of having automated policy enforcement at all levels, using verifiable metadata (i.e. labels). We've already got a good solution for the label part (DID documents), we just need a sample implementation of policies, even if our initial policy is just implicitly trusting the origin.

[Ipstenu]

Until we do that, the answer might be, "Well, @Ipstenu reviews everything personally, and if she doesn't know you...." 📦

More like "We're doing it by invite only at first"

We've already got a good solution for the label part (DID documents), we just need a sample implementation of policies, even if our initial policy is just implicitly trusting the origin.

First, for those who aren't aware, there's a concept of a Desire Path - read https://en.wikipedia.org/wiki/Desire_path for more if it's new to you! And I mention it because we have an idea of a path, but we're not sure how it'll be used in the wild :) So keep that in the back of your head and make flexible plans.

Now.

Package Identity is actually a subset of Repository identity. It's important to keep that in mind because it's possible FAIR won't actually have an open-submission repository! We can, and we might, but we also may not (why? because having a single monolithic repo doesn't solve the actual problem at hand). Instead, when I was writing up docs, I was focusing on "How do we monitor repositories and make sure they're doing what they should?"

Inherit trust from .org is fine for plugin/theme authors who publish their code on .org.

Agree :)

For authors who have removed their packages from .org already (or intend to), or no longer maintain their code on .org and are already today distributing updates outside of .org, there's a greater need to prioritize serving them over the FAIR protocol than .org, IMO. The landscape has already changed. Developers have already started doing this.

Also agree!

The answer is "You would make your own repository and submit that to the FAIR aggregator, where ..."

But again, I point back to invite only at first.

Why?

Because if we invite people we KNOW are who they are, we can build out the automated systems safely. We 'invite' AspireCloud (not really, but you know what I mean). We give them tags of 'aspirecloud' and/or 'wporg-mirror' etc etc. We also give them the 'fair-confirmed-as-legit'. We build out the auto-checks based on the real use, and then open the doors a little. This also lets us figure out the pain points of the repo code and update/fix and get things to a public beta stage.

Back to "Well, @Ipstenu reviews everything personally, and if she doesn't know you...."

So this is what's funny. The answer to "How do I get my packages in FAIR?" is "You submit to a repo" and the answer to "How does a repo decide I'm who I am?" is "They use their own Ipstenu clone" ;)

See, one of the problems with a monorepo like .org is that someone must review the code and the content. Not for code quality per se, but to make sure basic things like "Not phoning home" and "has a license" -- For that, we can auto-scan with https://github.com/WordPress/plugin-check-action or fork the internal scanner.

Which brings a different question: "What can we SAFELY automate checks for?"

Or maybe "What do we NEED to check before adding a repo?"

That is, what do we use to know you're YOU?

In no real order...

1. DID with DNS - this is relatively easy (see https://bsky.social/about/blog/4-28-2023-domain-handle-tutorial )
2. DNS and email - does the email the person used to submit match the domain? (if you use @gmail.com to submit a microsoft.com repo, you get auto-rejected)
3. Does the email WORK? (relatively easy again, and can be handled by making people register first and confirm emails)
4. Checksums to confirm package is package

Sadly DID (12345 === microsoft, for example) and Checksums all points back to a single 'verification' point....

[toderash]

Thanks @Ipstenu for engaging with all that so thoughtfully! A few notes to further discussion.

Package Identity is actually a subset of Repository identity.

Yes, agreed. The problem at hand is actually about author identity, but these are not unrelated since a Package inherently has at least one author, or publisher. We do get to that, but calling this a subset is helpful because it implies the possibility of the package inheriting trust from the repo... which, as noted, requires vetting the repo and their practice for accepting packages to host. With Mini-FAIR, this can be a conundrum, because it's likely easier to set up your own repo than get another one to host your thing.

"They use their own Ipstenu clone" ;)

Half-Elf has a Doppelgänger!

That is, what do we use to know you're YOU?

This is the crux of it. A package needs an identified & verified author, whether that is an individual or an organization. As described in the (admittedly lengthy) issue writeup and as pointed out by @jazzsequence, we don't have a standard written for that. The tech side is likely easier because we can automate a lot of it, but for author identity, we have to be able to tie the whole thing to an identifiable and verifiable individual or org for every package. Either we have a process for doing that ourselves, or we have a list of third-party verification systems we identify as trustworthy - i.e., their system of identity verification covers what we need.

Now we come to the problem we need to flag: the proposed and casually-accepted solution within all of the discussions does not do what we need it to. DNS verification won't work for our use case - all it does is ties a DID with a domain as an alias... and nothing more.

Consider the following real-world output from a whois request:

Registry Registrant ID: 
Registrant Name: REDACTED FOR PRIVACY
Registrant Organization: REDACTED FOR PRIVACY
Registrant Street: REDACTED FOR PRIVACY 
Registrant City: REDACTED FOR PRIVACY
Registrant State/Province: MB
Registrant Postal Code: REDACTED FOR PRIVACY
Registrant Country: CA
Registrant Phone: REDACTED FOR PRIVACY
Registrant Phone Ext: 
Registrant Fax: REDACTED FOR PRIVACY
Registrant Fax Ext: 
Registrant Email: https://tieredaccess.com/contact/5a43dbe0-0f59-4f03-bb61-d5c169cf5056

Suppose there was a txt record in the DNS for this, and it verified a DID: you've still got nothing to verify identity. As pointed out in the writeup, only certain types of SSL/TLS certificate include identity verification:

SSL/TLS certificate of the OV, IV, or EV type

These are generally uncommon, but would verify that the domain/website is verified & owned by the person/org they claim to be. Basically it could be made to work for a small subset of sites, but that's it.

[toderash]

So I think where we're at (subject to change, as ever!) is this:

Immediate:

• Inherit trust from dot-org for author identity with chain of continuity as described
• Admit new packages/authors by invitation only as a closed beta using the Mini-FAIR Repo plugin

Short-term next-steps:

• Review dot-org process & draft our own identity requirements for new authors/packages: what do we need to know to verify manually?
• Create a WG for package/author verification using a manual process
• Investigate using any third-party verification systems that confirm identity to the level we require, as a potential shortcut to simplify verification steps

And then, Potentially:

• Introduce manual and/or third-party verification during closed beta in order to open a public beta
• Vet the proposed verification system with larger hosts and key stakeholders

[Ipstenu]

Review dot-org process & draft our own identity requirements for new authors/packages: what do we need to know to verify manually?

Most of the .org process is checking for code. There is some pre-submission validation which checks things like "If a plugin is submitted with WooCommerce or Woo as the first word in the plugin name, is the email address one of the confirmed Woo email address?" (which is an array of the domains).

Honestly the work is really basic:

1. Check if the first word in the plugin name/slug is 'known' or trademarked
2. Verify the submitter is the owner

Sadly it's pretty manual since we don't have a list of all known products (it's kinda impossible). But ... God help me, this is where an AI would be helpful to flag a submission as "Possible infringement." We ended up hardcoding in a list :/ Not the best in the long run.

Since we have a DID, we can mimic the DNS stuff that BlueSky does. So...

1. DNS TXT Records for DID Verification - an automated system could query the domain—extracted from the package metadata or developer's website—and check for the matching DID in the TXT record.
2. Domain Ownership Linking - since each package already has a DID, linking that DID with a domain you control via DNS helps confirm the legitimacy of the claim.

With this setup, we can automate:

1. Extract the domain information from the plugin or theme metadata.
2. Perform a DNS TXT record lookup to retrieve the declared DID or verification token.
3. Compare this to the package's DID to confirm they match.
4. Compare the submitters email with the domain in that DNS (hah hah to all you gmail people)

Now that 4th one needs to be a flag only "submitter email does not match domain" for those gmail people.

Investigate using any third-party verification systems that confirm identity to the level we require, as a potential shortcut to simplify verification steps

What about GitHub? Assuming people need a user account to submit a package, we can have them connect their account/repo with the package? There's also GitLab and BitBucket

• https://docs.github.com/en/developers/apps/building-oauth-apps
• https://docs.github.com/en/developers/apps/authorizing-oauth-apps
• https://docs.gitlab.com/ee/integration/oauth_provider.html
• https://developer.atlassian.com/cloud/bitbucket/oauth-2/

Introduce manual and/or third-party verification during closed beta in order to open a public beta

3rd party would need... I think the flag "Trusted to Verify" (probably for hosts and big players like A8C, HumanMade, etc ;) ).

[toderash]

I understand how the DNS TXT record verification works, but again, it doesn't reliably establish a valid person/org identity on its own, though it could be used in conjunction with something else. This method associates a DID with a domain, but the domain must still be verifiable to an identifiable owner. As noted above, I can register a domain with a gmail address and fake personal information, then discard the email address and ignore the domain renewal - I'll have verified my DID against the domain's DNS entry by then, and you still won't know who I am.

I thought about GitHub OAuth integration to verify, and that'd be worth digging into more. The issue I see is that while it links the DID with the GH repo for the package, it does not identify or verify an individual / organization, since you can use a pseudonym on your account without providing actual ID info. It would get partway there though.

This is where we need to think through what we can get easily and what we actually need so we can do a proper gap analysis and work out a solution. I'm fairly sure we can do some level of identity verification through automated means. For example, today if I want to log into my account with the Canada Revenue Agency, I can use OAuth with my bank login. Gmail or any other OAuth platform isn't supported, because the OAuth provider has to have verified your identity... as my bank has, right down to my Social Insurance Number. Facebook might think they know me, but not to the satisfaction of the CRA.

I think there's a level between these that would work for us. iirc, even Airbnb has you photograph your drivers' license to compare with a live webcam shot. If it's not them, I've seen that elsewhere. For our purpose, OAuth from that level of verified third party may suffice to establish you are who you say you are. Do take a look at https://www.interac.ca/en/verification/personal/learn-about-interac-verified/ which is a Canadian provider, but there will be comparable services elsewhere. I imagine a range of supported options will be needed, with fallback to the old manual steps.

[tacoverdo]

This issue was started with the problem that we need to reliably tell that an author offering code to FAIR on repository X is the same author who used to offer that code through repository Y. Aka, if an author moves their contributions to a different repository, we need to be able to verify that's legitimately the same author, and not an imposter, correct?

We don't necessarily care if the author is named Joost, Mika, Juliette, Andy, Veerle or Taco. We don't need to know where they live, what car they drive or if they have a criminal record. We just want to be able to track them across platforms/repositories, right?

I'm asking because I'm seeing the conversation slowly shift towards reliably identifying the person(s) behind a piece of code, and I'm not convinced that's what we need to do here. As I understand it, an author doesn't have to be a natural person. It can also be an organization submitting a piece of code. And while using a domain TXT record tied to a DID doesn't tell me WHO the author is, I'd say it is sufficient to tell me it's the same author across repos.

So please help me understand why you think that's not sufficient.

[toderash]

I'm seeing the conversation slowly shift towards reliably identifying the person(s) behind a piece of code

Yes, you're reading that correctly! Also yes, the entity can be an organization or a natural person.

please help me understand why you think that's not sufficient.

This is based on feedback from some larger hosting companies that we really want/need to be on board with what we're doing so they can adopt it. I have not delved deeply into the coming CRA requirements, but one of those is a security contact, and I suspect we may find other requirements tied to identity. Offhand, one example could be that code ownership is important, even under a Copyleft license. Mainly though, this is about satisfying security requirements for hosts.

Currently on dot-org, you create and log into your account there before submitting a plugin/theme, so there's presumably some level of identification, at least to dot-org's satisfaction. I think that's likely not too deeply vetted and could be exploited, but the hosts are looking to us not to equal dot-org's level of security, but to be better.

This isn't strictly a technical requirement, but is a requirement for us to achieve significant adoption at the host level. Not trying to overstate it, but resolving this (or not) could have existential ramifications.

[Ipstenu]

Currently on dot-org, you create and log into your account there before submitting a plugin/theme, so there's presumably some level of identification, at least to dot-org's satisfaction. I think that's likely not too deeply vetted and could be exploited, but the hosts are looking to us not to equal dot-org's level of security, but to be better.

Nope!

Wanna know how it works?

You look at the plugin, you look at the account, and you look at the domain!

[toderash]

tbh I didn't think it was much more than that: "Yeah, this looks right" or "Hey, something's hinky" based on a SWAG. The fact they have a dot-org account with a listed email is as genuine as it gets (pretty minimal), and that's a very low bar. It's (more than) a little alarming, really.

Reminds me of the dream I had a few months ago where we discovered that all of dot-org's storage was JBOD. :P I think my subconscious keeps telling me things are not all that solid over there. ;-)

The fact is that whatever they've done in the past, we have to accept as our starting-point now. It'd be great to go back in time and change that, but variable time travel might be an unsolvable problem. (btw, I'm actually a time traveler, but I can only move forward, and only at a fixed rate.) Anyway, we're accepting that what we have - as minimal as it is - is the best starting point we can realistically achieve for those packages, and if we inherit something untrustworthy, we can transfer the blame.

@Ipstenu we'll be needing to lean heavily on your experience with the dot-org repos to highlight what they care (and don't care) about. This will help us assess threats that we can address in the short term and what we can defer. In the end, the analysis becomes a specific document detailing security differences between dot-org and FAIR, which will become very important very quickly.