Skip to content
This repository was archived by the owner on May 27, 2024. It is now read-only.

Spec: Define what files go into .reuse/ #29

Closed
carmenbianca opened this issue May 28, 2019 · 5 comments
Closed

Spec: Define what files go into .reuse/ #29

carmenbianca opened this issue May 28, 2019 · 5 comments
Milestone

Comments

@carmenbianca
Copy link
Member

Thread: #23 (comment)

Gist of it is: If we flatly allow all files in .reuse/ to be ignored by the linter, this opens vectors for abuse. (e.g., sneakily storing unlicensed code in there).

@silverhook @mxmehl @carmenbianca

@mxmehl
Copy link
Member

mxmehl commented May 29, 2019

I am not sure how realistic the sneaky scenario is. If someone sees need to prevent that, we can agree on a definition, or a name pattern and content description. Otherwise, I would keep it as general as possible like

The folder .reuse/ only contains files necessary for checking and ensuring REUSE compliance. Actual code or documentation must not be stored inside this folder.

@carmenbianca
Copy link
Member Author

I don't think anything needs to be changed here. There are a lot of vectors for abuse if you're looking for them. You could have a "./configure" script that downloads malware from the internet and puts it in "shady-directory", which is ignored by ".gitignore".

@silverhook
Copy link
Collaborator

silverhook commented May 31, 2019

Setting the backdoor argument aside, if .reuse/ will include stuff that will have to be parsed by REUSE tools, that stuff will have to be defined as well. As you define that, you can simply say that this is the only thing that is allowed in there.

I’m OK with setting this aside for a later revision, once we know what stuff we want/need in that folder.

@carmenbianca carmenbianca added this to the REUSE 3.1 milestone Jun 11, 2019
@carmenbianca
Copy link
Member Author

Added the REUSE 3.1 milestone for this.

@carmenbianca
Copy link
Member Author

Fixed by c534c57

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants