1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
|
HACKING GNOME KEYRING
Patches should be submitted to bugzilla:
http://bugzilla.gnome.org/enter_bug.cgi?product=gnome-keyring
Gnome Keyring is made up of several distinct parts working on concert with
each other. These parts generally live in different directories:
daemon
The main daemon startup code and gnome-keyring password protocol operations.
daemon/keyrings
Code that manages the user's password keyrings
daemon/pk
General public key / certificate code, management of objects.
daemon/pkcs11
The PKCS#11 part of the daemon.
daemon/pkix
Nitty gritty handling of various PKCS#?? standards, parsing, ASN.1 stuff.
daemon/ui
Prompting the user, asking for passwords.
library
The gnome-keyring library for accessing passwords and secrets.
pkcs11
The PKCS#11 module, provider and headers.
tests
Test tools and unit tests.
--------------------------------------------------------------------------------
USING 'LOCATIONS' INSTEAD OF FILE PATHS
Gnome Keyring supports having keyrings on removable media. Because removable
media can be mounted in different mount-points, and for other related reasons,
what's called a 'location' is used instead of a file point.
Locations are like paths relative to a base. For example certain locations
might be relative to a home directory, and others might be relative to a USB
drive.
Location functionality:
common/gkr-location.h
Common functions:
gkr_location_from_path ()
gkr_location_from_child ()
gkr_location_to_path ()
--------------------------------------------------------------------------------
USE OF WORKER THREADS
Gnome Keyring uses threads in a limited manner, as state machines, (ie: execution
stacks). Only one thread runs at any given time, each thread hands off execution
to another thread.
The *only* use of threading and/or synchronization primitives should be in:
common/gkr-async.c
Worker threads are created by using gkr_async_worker_start(). Each worker needs
to call gkr_async_yield() regularly, to give other threads a chance to run.
If a thread needs perform a blocking syscall, or do something that takes a long
time (like create a key) it can use the gkr_async_begin_concurrent() and
gkr_async_end_concurrent() functions. While running 'concurrent' no global
functions and/or data should be accessed.
|
