View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0002416 | gnunet-gtk | gnunet-fs-gtk | public | 2012-06-11 14:19 | 2012-11-05 18:32 |
Reporter | LRN | Assigned To | Christian Grothoff | ||
Priority | urgent | Severity | minor | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Product Version | Git master | ||||
Target Version | 0.9.4 | Fixed in Version | 0.9.4 | ||
Summary | 0002416: GNUnet fails to create namespace with wrong names | ||||
Description | GNUNET_FS_namespace_create() creates a file that stores namespace key. File name == namespace description. If namespace description contains invalid characters (such as '?' on W32), GNUNET_FS_namespace_create() fails and returns NULL. gnunet-fs-gtk_create-pseudonym.c calls GNUNET_FS_namespace_delete() for it immediately, not bothering to check that ns is NULL. Anyway, i think that using arbitrary strings for filenames might be error-prone. Maybe use key hashes or something? On the other hand, they don't have any metadata, and the only things that help one to identify them are their filenames...Normalize them? | ||||
Tags | No tags attached. | ||||
|
I guess using the encoded hash as the namespace filename might be best. Maybe 'struct GNUNET_CRYPTO_ShortHashAsciiEncoded' to get a slightly shorter filename (as the very long filenames sometimes also cause problems on some file systems). |
|
yes, but how are you going to show a list of identities to the user? The files do not have any data other than the key (AFAIK). You need also to add some kind of description to key files. |
|
Sure, I thought the metadata was serialized as well. But that problem would exist either way, as with canonicalization the descriptions would also be garbled. |
|
Ok, went over the code. The 'name' here is clearly supposed to be a valid filename; GNUNET_FS_namespace_create is also used to open an existing namespace file, so the 'name' argument must be a valid filename, otherwise the whole API won't work. Also, changing this will break backwards-compatibility badly. So I think the answer is to restrict the legal characters in gnunet-fs-gtk (and likely gnunet-pseudonym) and of course check for the return value being NULL. |
|
SVN 21978 restricts characters for pseudonym names to alpha-numerical and "_" and "-", which should be pretty safe. (Albeit possibly inconvenient for international users, dealing with non-English characters that are safe for filenames is left as an exercise to the reader ;-).) |
Date Modified | Username | Field | Change |
---|---|---|---|
2012-06-11 14:19 | LRN | New Issue | |
2012-06-12 12:05 | Christian Grothoff | Note Added: 0006046 | |
2012-06-12 12:05 | Christian Grothoff | Assigned To | => Christian Grothoff |
2012-06-12 12:05 | Christian Grothoff | Status | new => confirmed |
2012-06-12 12:05 | Christian Grothoff | Assigned To | Christian Grothoff => |
2012-06-12 12:05 | Christian Grothoff | Target Version | => 0.9.4 |
2012-06-12 12:11 | LRN | Note Added: 0006047 | |
2012-06-12 12:17 | Christian Grothoff | Note Added: 0006048 | |
2012-06-12 20:54 | Christian Grothoff | Priority | low => high |
2012-06-13 11:12 | Christian Grothoff | Assigned To | => Christian Grothoff |
2012-06-13 11:12 | Christian Grothoff | Status | confirmed => assigned |
2012-06-13 11:12 | Christian Grothoff | Priority | high => urgent |
2012-06-13 17:55 | Christian Grothoff | Note Added: 0006065 | |
2012-06-13 18:16 | Christian Grothoff | Note Added: 0006066 | |
2012-06-13 18:16 | Christian Grothoff | Status | assigned => resolved |
2012-06-13 18:16 | Christian Grothoff | Fixed in Version | => 0.9.4 |
2012-06-13 18:16 | Christian Grothoff | Resolution | open => fixed |
2012-11-05 18:32 | Christian Grothoff | Status | resolved => closed |