author, instructor: read and use participants file

[prechelt]

Config sedrila.yaml should allow an entry as follows:

participants:
  file: myparticipants.tsv
  file_column: studentID
  student_property: student_id

with the following meaning:

1. sedrila author will read the file myparticipants.tsv and interpret it as a TAB-separated values file with a header row
2. it will collect all entries from column studentID in that file and consider this the set of participants of this sedrila course instance
3. this set will be included in the instructor web site generated as the file participants.list, a plain text file with one studentID per line
4. sedrila instructor will read this file as the set of participants of the course
5. it will check whether the student_id entry in the student.yaml of the current student is in the set.
   If it is not, a warning will be issued that this student is not a member of the course.
   The idea is that the instructor can then perform appropriate steps such as rejecting the judging of the submission, asking the student to fix their metadata, or asking the organizer to fix the participants list.

[prechelt]

Steps 1-3 are done.

[prechelt]

Step 4 involves a privacy issue: The participantlist contains person-identifiable data and should not be public.
The obvious solution is storing the participantlist in the non-public instructor website. But then, the instructor needs to authenticate for accessing it. For the web pages viewed in the browser, this is not a problem, as the browser keeps the password as long as it runs.
For sedrila instructor, however, this would mean to authenticate each time it is called, which is both inconvenient and insecure.

There are several possible approaches around this:

1. Keep the credentials for basic authentication on the instructor's computer. There are many solutions for this, but they are all either heavyweight (involving additional infrastructure such as a secrets store of some sort which makes an instructor setup complex) or not very secure (environment variables, which could leak e.g. if the instructor ever executes student code).

2. Use asymetric encryption. This is safe, but requires complex code within sedrila. It would work as follows:

• Store the participantslist file in the student website, not the instructor website.
• Encrypt it symmetrically with a random key
• Encrypt that key asymmetrically separately for each instructor.
• Provide the encrypted keys in a json file, to be found via the instructor's keyfingerprint.

This approach means, sedrila instructor needs to call gpg whenever a participantslist exists.

3. Consider the participantslist to be public.

4. Store participantslist in student website, encrypt it symmetrically, and pre-share the key with the instructors via a separate channel.
   This is less convenient than using environment variables for basic authentication, but the risk of leaking would then pertain only to the participantslist, not the entire instructor account.