securitytxt/securitytxt.org

Static website for security.txt.

securitytxt.org's Issues

security.txt has expired on 2024-03-14

The key used to sign the current security.txt that Expires: 2024-03-14T00:00:00.000Z has expired on Wed 23 Aug 2023.

gpg: Signature made Wed 01 Feb 2023 06:20:57 PM EET
gpg:                using EDDSA key AC3F6904768283545A5283ABB7ACAF980A48DAA7
gpg: Note: signature key B7ACAF980A48DAA7 expired Wed 23 Aug 2023 12:34:19 PM EEST
gpg: Note: signature key B7ACAF980A48DAA7 expired Wed 23 Aug 2023 12:34:19 PM EEST
gpg: Note: signature key B7ACAF980A48DAA7 expired Wed 23 Aug 2023 12:34:19 PM EEST
gpg: using pgp trust model
gpg: key 50C62EAE952C56BF: accepted as trusted key
gpg: key 3B04D423957EFE0F: accepted as trusted key
gpg: Good signature from "Ed Foudil <[email protected]>" [expired]
gpg: Note: signature key B7ACAF980A48DAA7 expired Wed 23 Aug 2023 12:34:19 PM EEST
gpg: Note: This key has expired!

The RFC 9116, 2.5.5 does not have a recommendation against signing a security.txt with a key that expires before the signed file becomes stale. In my opinion it should have had, as it does not make much sense to trust the information if you do not trust the signature. (For this reason, my securitytxt-signer.sh L115-134 never accepts an expiry date that is further in the future.)

"mailto:" is missing from generated mail Contact lines

I just dropped you a mail (but cannot find it anymore, so cannot copy it)… (If you still have it, copy it here)
Ah, it was the contact formula! If you still have that, feel free to copy it in here.

In any case, the issue is the spec mandates mailto: for mails, but your generator generates (thus) "non-compliant" Contact lines without that prefix.

add "unfurl" link-preview summary to main website

It would be great if pasting the https://securitytxt.org/ URL to social media (like Slack chat) would automatically result in extra link preview info unfurl with a few lines of text and maybe even a pic.

securitytxt/security-txt#27

Validate the form for generating security.txt files

It'd be great to make sure people creative valid security.txt files. Some validation could include:

• Verifying that a : was included in the value of the Contact: directive (this would catch people who don't include mailto: and just put an email address directly) -- this error could probably be ignorable.
  This could also apply to [and even be a bit stricter there (require URLs only, for example)]
  • Policy
  • Hiring
• Ensuring that a Contact: directive is set
• Ensuring that the Preferred-Languages directive only contains commas, dashes, spaces, and letters

New field: Expires

Blocked by securitytxt/security-txt#183

• Only one allowed
• Ideally, can be inputted using a date picker? (either through browser or a Bulma extension) -- then the JS will get it into a compliant format

The date/time after which the data contained in the "security.txt"
file is considered stale and should not be used

Update generator to support the RFC 3339 / ISO 8601 format

This is for the upcoming -12 version

Add `CSAF` field

It would be great if the CSAF field from the registry could be added to the generator: https://www.iana.org/assignments/security-txt-fields/security-txt-fields.xhtml
The related ticket is securitytxt/security-txt#200

Reword "Only 1 allowed" label in security.txt file generator.

The current label is a bit confusing. Maybe we could reword it.

Accept other contacts

The form on the page only accepts https or mailto. However, I would like to also provide a matrix account via the matrix: scheme ( https://www.iana.org/assignments/uri-schemes/prov/matrix ) as their system provides end to end encrypted chats which is a nice way to do direct messaging for further talking. The security.txt here would verify my user id for this communication.

Dead link for Chrome-Extension

https://github.com/securitytxt/Extension in Security.txt projects is dead and should be relinked, replaced or deleted.

Improve forms

Hi, I am Aasheesh. I have recently send a contact message, as below screenshot

I said that I will improve your form. Anyways, here I have came to improve it.

A issue that you are using is, that. you are using Formspree for your forms. I'd like you to use FormSubmit, which is a totally free, unlimited service for email responses, similiar to Formspree. FormSubmit is completely customizable, for example, you can edit the success page, so the user will always be in your website, and won't go to any other.

Similiar to FormSpree, go formsubmit.com and read how you can add your form, also scroll down for cool options.

email mentioned in FAQ as optional

Hi,
email mentioned in FAQ as optional but in form it's required

Ammendments to the FAQ

These include mentioning that the project is not just for websites, optimising for automatic translators for acronyms by using the correct tags, and noting the fallback path of /.

Newline missing in generated form for Expires

When generating a form with the new Expires field it does not generate a new line after the expiration so any field following start on the same line.

I have a PR which should be attached shortly to quickly add it, but let me know if there is any other process that needs to be followed.

Cache invalidation

Some pull requests target both the HTML and the JavaScript files. Often, the changes to the JavaScript rely on the changes in the HTML, and this can cause fatal errors to occur until the cache is updated.

This is an issue we experienced during the merging of #29

My understanding is that the template is compiled into HTML once, and then served. This means that the correct approach is simply to (using one of Liquid's built-in commands) append the timestamp as a querystring to the path of the JavaScript and CSS files.

Add a separate security.txt checker/validator textarea field.

Someone requested this via email:

Please add a security.txt checker/validator on the securitytxt.org site. People seem to have a hard time understanding the specification fully, so a checker would help proper deployment. I recommend having an input field for the main domain.

Add multiple social media share buttons

Currently we only have a twitter share widget. We should add other options.

Cloudflare breaks the HTML form for Tor users.

Someone brought it to my attention that the form does not work for Tor users because of Cloudflare's WAF rules. We load the JavaScript files from Cloudflare's CDN which is causing trouble for some users. On top of that, the user experience on securitytxt.org for Tor users is severely impaired due to the Captchas they have to solve.

Some options:

• (If possible) Configure Cloudflare to be more lenient towards Tor users;
• Create a .onion fork of the securitytxt.org website.

I am open to other suggestions.

cc: @jamieweb might know more on this subject.

Please switch to iso standard for datetimes

Date time fields would be better if using international standards as ISO 8601 rather than RFC 5322 which includes language specific strings.

List third-party libraries & parsers

It would be nice to have a little section on securitytxt.org that lists third-party tools related to security.txt.

See: securitytxt/security-txt#40

security.txt not well-formatted

Hi everyone,

When I ran sectxt against securitytxt.org, I noticed that the security.txt file is not validated successfully.

$ curl -LSs https://raw.githubusercontent.com/securitytxt/securitytxt.org/master/.well-known/security.txt | hexyl
┌────────┬─────────────────────────┬─────────────────────────┬────────┬────────┐
│00000000│ 2d 2d 2d 2d 2d 42 45 47 ┊ 49 4e 20 50 47 50 20 53 │-----BEG┊IN PGP S│
│00000010│ 49 47 4e 45 44 20 4d 45 ┊ 53 53 41 47 45 2d 2d 2d │IGNED ME┊SSAGE---│
│00000020│ 2d 2d 0a 48 61 73 68 3a ┊ 20 53 48 41 35 31 32 0a │--_Hash:┊ SHA512_│
[...]

Here you see that the first line ends with \n; but RFC 9116 specifies the cleartext header lines to end in \r\n:

cleartext-header =  %s"-----BEGIN PGP SIGNED MESSAGE-----" CRLF
[...]
CRLF             =  CR LF

My guess is that this happens due to Git, which normalizes newlines. You can ask Git to treat the file as binary using a .gitattributes file.

Please note: this is also true for other lines of the cleartext message, except for the actual cleartext body.

Expires field missing

The provided Tool is seemingly not up to date.
The expires field which is introduced in Version 9 from the draft isn't provided.
Futhermore the missing expires field is marked as required in Version 10.

Also, as a suggestion I'd like to add that a user is informed about the current draft version the Tool supports.

Allow 'chaining' of directives in the form that generates them

We could have a + icon next to directives that are chainable (i.e., directives which can appear multiple times in the document). Clicking on this plus icon would lead to a new input box, with the same heading as the one from which it stemmed.

The new input boxes could have - (or x) icons to remove them.

Modernize JS/EcmaScript

as from #83 (comment)

Use templating language to avoid repetition

The HTML structure of the Step 1 form is very repetitive. Each directive has a very similar structure.

We could simplify the source code by taking advantage of the templating language Jekyll uses, Liquid, to loop through all the directives. This way, we only need to write the HTML for the directives once.

We would use conditionals to add validation (suhh as "required"), as well as to disable buttons where a directive is only allowed one alternative.

If we do this, we can make modifications more quickly, as it is very tedious to make the same change 7 times.

Move FAQ above generating form

The FAQ is much shorter than the generating form (in particular now because of the height of the form). To ensure everyone knows the FAQ exists, perhaps it should be moved to the top of the page.

An internal navigation bar is another alternative.

Translate

It will be good to offer the tools in several language.
This will help people around the world to adopt this more easily.