himitsustore.org: add subtitles to video v1 APPLIED

Jackson Chen: 1
 add subtitles to video

 2 files changed, 305 insertions(+), 1 deletions(-)
#1050876 .build.yml failed
Export patchset (mbox)
How do I use this?

Copy & paste the following snippet into your terminal to import this patchset into git:

curl -s https://lists.sr.ht/~sircmpwn/himitsu-devel/patches/44264/mbox | git am -3
Learn more about email & git

[PATCH himitsustore.org] add subtitles to video Export this patch

same as the one provided for the PeerTube video
 index.html |   4 +-
 intro.vtt  | 302 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 305 insertions(+), 1 deletion(-)
 create mode 100644 intro.vtt

diff --git a/index.html b/index.html
index 8873db8..23bb220 100644
--- a/index.html
+++ b/index.html
@@ -26,7 +26,9 @@
  <div class="center">「パスワードは何?」「ひみつですよ!」</div>

  <video src="intro.mp4" controls></video>
  <video src="intro.mp4" controls>
    <track label="English" kind="subtitles" src="intro.vtt" srclang="en" default />

    Himitsu is a secure secret storage system for Unix-like systems. It provides
diff --git a/intro.vtt b/intro.vtt
new file mode 100644
index 0000000..16192fd
--- /dev/null
+++ b/intro.vtt
@@ -0,0 +1,302 @@

00:00:00.920 --> 00:00:05.370
Hello! My name is Drew DeVault and I am the designer Himitsu key store system,

00:00:05.370 --> 00:00:07.050
And I'd like to present it to you today.

00:00:07.720 --> 00:00:13.180
What you see in front of you is a GTK+ frontend for the Himitsu key store, which is called keyring

00:00:13.180 --> 00:00:15.030
And is written by Martijn Braam.

00:00:15.820 --> 00:00:19.400
On the left here, you see a series of keys which is stored in the key store,

00:00:19.400 --> 00:00:23.710
These are web passwords, this one for example is for alpinelinux.org,

00:00:23.710 --> 00:00:30.060
And it includes the protocol as web, the hostname the username, and the password which is currently hidden.

00:00:31.290 --> 00:00:37.040
The core key store implementation does not understand the semantics of any particular kind of secret.

00:00:37.040 --> 00:00:41.060
So a web password is defined by convention.

00:00:42.400 --> 00:00:45.340
So the key store stores arbitrary key value pairs,

00:00:45.690 --> 00:00:48.950
And there are conventions associated with the web protocol.

00:00:48.950 --> 00:00:54.070
Specifically for this protocol, each of the keys are form fields,

00:00:54.070 --> 00:00:59.310
And the values are the values that should be placed into those forms to complete filling out a login form.

00:00:59.880 --> 00:01:04.240
Here the username field is called user and the password field is called password,

00:01:04.240 --> 00:01:06.530
But there are other examples, for example

00:01:06.530 --> 00:01:12.120
Codeberg calls the username form field "user_name", and thus it has a different key value.

00:01:12.680 --> 00:01:19.800
But the actual semantics structure of these keys is beyond the concern of Himitsu,

00:01:19.800 --> 00:01:24.260
Which allows us to implement more kinds of keys to be stored than simply passwords.

00:01:24.780 --> 00:01:31.890
For example, I also have in my key store an XMPP credential, IRC credentials, Matrix credentials,

00:01:32.280 --> 00:01:37.890
SMTP credentials, this one is interesting because we see different conventions for how these are stored.

00:01:37.890 --> 00:01:44.430
This includes the port number to connect to, and the TLS method in use, in addition to all of the the other similar keys.

00:01:44.430 --> 00:01:47.450
But I'll expand a little more on these other kinds of keys later.

00:01:47.920 --> 00:01:50.120
For now I'd like to focus on the web keys.

00:01:50.120 --> 00:01:57.220
I have here one for example.org, which I can view by pressing "Decrypt".

00:01:57.220 --> 00:02:01.110
And I'm given this prompt to consent the disclosure of my secret information.

00:02:01.110 --> 00:02:04.040
And if I agree, it shows the password here.

00:02:05.480 --> 00:02:11.050
I can also show you a different front end for accessing Himitsu, which is our Firefox plugin.

00:02:11.490 --> 00:02:13.600
So we have an add-on here which adds a button.

00:02:13.600 --> 00:02:19.050
When I click this button, it looks up and displays all of the Himitsu entries which match this hostname.

00:02:19.370 --> 00:02:20.750
If I click autofill,

00:02:20.750 --> 00:02:26.490
Again, I have to give permission, and if I agree, it fills in the form, and I am able to login.

00:02:28.350 --> 00:02:33.590
The difference of these two frontends, there's a frontend that comes with the Himitsu distribution called hiq.

00:02:33.940 --> 00:02:39.030
This is a command line program which is used to facilitate programmable access to the key store.

00:02:39.370 --> 00:02:43.330
Just running hiq displays all the keys, but I could be more specific.

00:02:43.930 --> 00:02:49.830
I can for example display only web keys, or I could display web keys for the host=example.org

00:02:50.690 --> 00:02:55.940
You'll notice here that the password field is marked with an exclamation mark, which indicates that it's secret

00:02:55.940 --> 00:02:57.930
And the value is not shown.

00:02:58.260 --> 00:03:04.610
If I want to display the value, I must give permission by using the d flag, and agreeing to that disclosure.

00:03:04.610 --> 00:03:06.090
And the password will be shown.

00:03:06.690 --> 00:03:13.310
We also have a feature in hiq, which is the f flag, which allows me to display a specific key only.

00:03:15.040 --> 00:03:17.320
This is useful for piping in shell scripts.

00:03:17.950 --> 00:03:22.910
There additionally more sophisticated queries that you can use,

00:03:22.910 --> 00:03:28.610
So I can say for example that I would like to view keys where proto=web and host=example.org

00:03:28.610 --> 00:03:31.710
Which also conforms to some desired characteristics such as

00:03:31.710 --> 00:03:35.340
Having username field with the password field, which is secret,

00:03:35.340 --> 00:03:38.960
And it will return all of the results which match this query.

00:03:38.960 --> 00:03:43.650
I can also add an optional comment field, which is not present but still causes key to be matched.

00:03:44.270 --> 00:03:50.490
And I can perhaps give a few more examples if I don't specify that hostname I want, and you can see a few other keys

00:03:50.490 --> 00:03:51.770
which match this shape.

00:03:53.810 --> 00:03:56.420
And other parts in we have is the SSH protocol.

00:03:56.420 --> 00:04:00.110
So again, Himitsu store is much more than web passwords.

00:04:00.440 --> 00:04:05.510
So if I query for proto=ssh, I will see that a SSH key in the store.

00:04:05.900 --> 00:04:10.570
And the exclamation part- mark here indicates that the secret key is secret.

00:04:10.570 --> 00:04:15.640
Public key is base64 encoded, we also have the the SSH key type

00:04:15.640 --> 00:04:18.690
And a comment, which comes from the public key file.

00:04:19.280 --> 00:04:24.200
I'm going to delete this key to show you how the system works.

00:04:24.880 --> 00:04:33.090
So deletion is a destructive operation which requires consent again, so I will agree to delete this key before moving on.

00:04:34.270 --> 00:04:42.020
And then I'll reimport my key using the hissh-import command, which I'll pass through the standard input,

00:04:42.020 --> 00:04:44.590
Path to my SSH key...

00:04:47.400 --> 00:04:48.340
Decrypt that key,

00:04:48.340 --> 00:04:50.400
And it'll be added to the key store again.

00:04:52.480 --> 00:04:54.200
Now that the key is in the key store,

00:04:54.200 --> 00:05:01.330
I can use the Himitsu SSH agent to facilitate the use of this key, with SSH applications.

00:05:02.240 --> 00:05:08.010
But for example, if I run ssh-add -l, you'll see that the key appears in this key store,

00:05:08.010 --> 00:05:14.910
And if I do an actual SSH command, I will be prompted to consent to the use of my secret key.

00:05:15.290 --> 00:05:18.400
And when I agree, the agent will facilitate the login.

00:05:19.730 --> 00:05:22.580
I can also use the hissh-export command

00:05:24.020 --> 00:05:28.930
Which will export any public keys which are found in the key store,

00:05:28.930 --> 00:05:35.420
So that you can re-import them into OpenSSH or add them to authorized_key file or something similar.

00:05:35.420 --> 00:05:40.030
It also supports a flag to export the SSH private key as well.

00:05:41.520 --> 00:05:46.450
The protocol which is used by the Himitsu daemon is very simple and straightforward,

00:05:46.450 --> 00:05:51.170
It's a line oriented text protocol, which works over a Unix socket.

00:05:54.860 --> 00:05:58.470
And in fact, we can demonstrate it by using netcat.

00:05:58.820 --> 00:06:05.230
So I can again query the keys with proto=web, I can decrypt a key with the -d flag,

00:06:07.480 --> 00:06:11.460
Which prompts me to consent, and when I agree, it displays the key here,

00:06:11.460 --> 00:06:14.560
And all of the other operations are equally simple.

00:06:15.380 --> 00:06:19.880
This uh, very straightforward protocol makes it very easy to build new integrations with frontends

00:06:19.880 --> 00:06:23.250
like the SSH integration, or the Firefox add-on,

00:06:23.250 --> 00:06:29.130
And my hope is that this will facilitate the development of robust ecosystem of programs

00:06:29.130 --> 00:06:33.280
which interact with the Himitsu key store, thanks to this very simple protocol.

00:06:33.970 --> 00:06:40.320
We also have a protocol for the prompter itself, so if I run hiq -d host=example.org,

00:06:42.160 --> 00:06:47.860
You see this GTK application pop up using the Wayland layer shell protocol.

00:06:47.860 --> 00:06:50.520
And this application itself is also pluggable,

00:06:50.520 --> 00:06:53.920
and is distributed separately from the core Himitsu application.

00:06:53.920 --> 00:06:55.680
It can be replaced with any implementation,

00:06:55.680 --> 00:07:00.380
You can replace it with something that uses QT instead of GTK+,

00:07:00.380 --> 00:07:05.670
You can replace it with something that prompts for permission on a TTY instead of using a GUI,

00:07:05.670 --> 00:07:09.990
You can replace them with something that integrates with Twilio to text you

00:07:09.990 --> 00:07:12.950
And ask you to confirm on your phone,

00:07:12.950 --> 00:07:17.350
Or any kind of use case you can imagine, through a simple standardized protocol.

00:07:17.990 --> 00:07:23.040
[The] protocol is documented along with all of the other features, in an extensive set man pages.

00:07:26.050 --> 00:07:27.980
The Himitsu-prompter man page

00:07:27.980 --> 00:07:32.150
Covers the protocol for the prompter to facilitate the prompter implementations,

00:07:32.150 --> 00:07:37.750
And the Himitsu-ipc man page covers the unix socket protocol that could be used

00:07:37.750 --> 00:07:39.250
to access the key store.

00:07:39.630 --> 00:07:44.600
We also have more man pages for the daemon, and introducing the system as a whole,

00:07:44.600 --> 00:07:49.470
Or talking about hiq or working with the SSH integration and so on.

00:07:50.560 --> 00:07:56.220
But this is the Himitsu system, hope you find it interesting, and I hope that you're able to build interesting things with it,

00:07:56.220 --> 00:07:58.630
Thanks for your attention, and be sure to check it out.

00:07:58.630 --> 00:07:59.250
(Subtitles provided by jacksonchen666)

himitsustore.org/patches/.build.yml: FAILED in 24s

[add subtitles to video][0] from [Jackson Chen][1]

[0]: https://lists.sr.ht/~sircmpwn/himitsu-devel/patches/44264
[1]: mailto:jackson@jacksonchen666.com

✗ #1050876 FAILED himitsustore.org/patches/.build.yml https://builds.sr.ht/~sircmpwn/job/1050876

To git@git.sr.ht:~sircmpwn/himitsustore.org
   3c03687..d44d4ec  master -> master