[libdvdcss-devel] Please implement the XDG basedir spec

[Torben Andresen]

Hi,

please implement the XDG basedir specification
(http://standards.freedesktop.org/basedir-spec/latest/) The benefit
will be an clean $HOME and that will help me and other user to make an
Backup just with the needed folders.

Thanks.

Kind regards

Torben

[Diego Elio Pettenò]

If you're referring to ~/.dvdcss I think we discussed that before and the
problem was with considering it cache.

I'm sure I still have the patches for that somewhere, should we use share
instead?

Diego Elio Pettenò — Flameeyes

Hi,
please implement the XDG basedir specification (
http://standards.freedesktop.org/basedir-spec/latest/) The benefit will
be an clean $HOME and that will help me and other user to make an Backup
just with the needed folders.
Thanks.
Kind regards
Torben
_______________________________________________
libdvdcss-devel mailing list
https://mailman.videolan.org/listinfo/libdvdcss-devel

[Torben Andresen]

Yes, that's what i meant. Use "$XDG_DATA_HOME/dvdcss" as folder. This will save the files in "$HOME/.local/share".

If you're referring to ~/.dvdcss I think we discussed that before and the problem was with considering it cache.
I'm sure I still have the patches for that somewhere, should we use share instead?
Diego Elio Pettenò — Flameeyes

Hi,
please implement the XDG basedir specification (http://standards.freedesktop.org/basedir-spec/latest/) The benefit will be an clean $HOME and that will help me and other user to make an Backup just with the needed folders.
Thanks.
Kind regards
Torben
_______________________________________________
libdvdcss-devel mailing list
https://mailman.videolan.org/listinfo/libdvdcss-devel

[Rémi Denis-Courmont]

Hello,

Post by Diego Elio Pettenò
If you're referring to ~/.dvdcss I think we discussed that before and the
problem was with considering it cache.

It *is* cached data. It is generated from the disc, and can *normally* be
fully regenerated. That is pretty much the definition of cache.

Of course, there are scenarii whereby regeneration may fail. That does not
make the data any less cached data. By the same line of thinking, it might be
impossible for my MUA to fetch an mail from IMAP again (because it got
archived), or for my web browser to retrieve a page (because it got deleted,
changed, or I lost access rights).


If someone wants to save their cache in their backup, or manually inserting
entries there, nobody prevents them from doing.

[Diego Elio Pettenò]

You don't have to convince me. I sent the original patches to consider it
so.

[Reimar Döffinger]

The proposed patch uses data, not cache, so I think this is besides the point, but anyway.
Skip it if you don't want to read rants...

Post by Rémi Denis-Courmont

Post by Diego Elio Pettenò
If you're referring to ~/.dvdcss I think we discussed that before and the
problem was with considering it cache.

It *is* cached data. It is generated from the disc, and can *normally* be
fully regenerated. That is pretty much the definition of cache.

That is one commonly encountered property of a cache, that is can be re-filled.
And even that one is not properly satisfied here (your examples aren't quite the same, since there the authoritative source changed, and the cache is intentionally supposed to reflect that)
Other properties caches often have:
They can not contain all data (not true here, there probably would be no problem storing keys of all DVDs ever produced)
They are an exact or simplified copy of the base data (not even remotely true here)

Post by Rémi Denis-Courmont
If someone wants to save their cache in their backup, or manually inserting
entries there, nobody prevents them from doing.

Not to mention simply considering the _purpose_ of having a separate cache directory: to allow people to make small, but still complete backups.
Putting the keys in the cache does not reduce the backup size in any relevant way, so I simply see no _advantage_ to considering it a cache.
Though I grant you that with libdvdcss the situation is not as inane as with libaacs, where you ate basically guaranteed to lose access to your BluRays if you don't backup your .cache and the only way to get it back is to buy a new (but not too new) drive or hope someone publishes a new host key...

Regards,
Reimar

[Rémi Denis-Courmont]

Post by Reimar Döffinger
The proposed patch uses data, not cache, so I think this is besides the
point, but anyway. Skip it if you don't want to read rants...

Post by Rémi Denis-Courmont

Post by Diego Elio Pettenò
If you're referring to ~/.dvdcss I think we discussed that before and the
problem was with considering it cache.

It *is* cached data. It is generated from the disc, and can *normally* be
fully regenerated. That is pretty much the definition of cache.

That is one commonly encountered property of a cache, that is can be
re-filled. And even that one is not properly satisfied here (your examples
aren't quite the same, since there the authoritative source changed, and
the cache is intentionally supposed to reflect that)

If you change drive type, the "authoritative source" changed all the same, as
if my IP address changes and the web content is GeoIP-based.

Post by Reimar Döffinger
They can not contain all data

That's not a common property of a cache. My IMAP cache may contain all my
mails, or it may contain only headers. My web content cache contains entire
files, or it may contain partially downloaded files.

Post by Reimar Döffinger
They are an exact or
simplified copy of the base data (not even remotely true here)

It is a presumably exact copy of the decryption key material, indexed by the
volume identifier or whatever.

Post by Reimar Döffinger
Not to mention simply considering the _purpose_ of having a separate cache
directory: to allow people to make small, but still complete backups.

Yes. If my hard-drive crashes, I won't need to restore the DVD decryption
keys; they can be regenerated from the same disc and drive. It is cached data
and I don't need to back it up (but I can if I want to).

Post by Reimar Döffinger
Putting the keys in the cache does not reduce the backup size in any
relevant way, so I simply see no _advantage_ to considering it a cache.

That's hardly relevant. And you are assuming that only a small number of discs
will ever be inserted in a given system. That's not necessarily true (public
library?).

And I have read complaints about the lack of privacy associated with the
DVDCSS key cache. Marking its content for backup makes matters worse, rather
than better.

Post by Reimar Döffinger
Though I grant you that with libdvdcss the situation is not as inane as
with libaacs, where you ate basically guaranteed to lose access to your
BluRays if you don't backup your .cache and the only way to get it back is
to buy a new (but not too new) drive or hope someone publishes a new host
key...

Device keys are obviously not cache content, and I guess you mean that MKB,
for practical reasons, should also not be considered as such.

Volume keys are probably cache content though. But that is off-topic.

[Reimar Döffinger]

I'll allow myself one more reply (one per actual review :-P )

Post by Rémi Denis-Courmont

Post by Reimar Döffinger
That is one commonly encountered property of a cache, that is can be
re-filled. And even that one is not properly satisfied here (your examples
aren't quite the same, since there the authoritative source changed, and
the cache is intentionally supposed to reflect that)

If you change drive type, the "authoritative source" changed all the same, as
if my IP address changes and the web content is GeoIP-based.

The big difference is that for the web the "authoritative source" if considered benevolent (i.e. if something was removed, it's overall reasonable to assume there is no reason to keep it).
libdvdcss clearly is in a completely different situation.

Post by Rémi Denis-Courmont

Post by Reimar Döffinger
They can not contain all data

That's not a common property of a cache. My IMAP cache may contain all my
mails, or it may contain only headers. My web content cache contains entire
files, or it may contain partially downloaded files.

I wrote "common" first but then explicitly changed it.
Nevertheless, your web content cache most certainly neither can or does contain the entire web.

Post by Rémi Denis-Courmont

Post by Reimar Döffinger
They are an exact or
simplified copy of the base data (not even remotely true here)

It is a presumably exact copy of the decryption key material, indexed by the
volume identifier or whatever.

I would consider anything the DVD drive gives us as the base data, and at least if the drive is region free the key is not exactly similar to that.

Post by Rémi Denis-Courmont

Post by Reimar Döffinger
Not to mention simply considering the _purpose_ of having a separate cache
directory: to allow people to make small, but still complete backups.

Yes. If my hard-drive crashes, I won't need to restore the DVD decryption
keys; they can be regenerated from the same disc and drive. It is cached data
and I don't need to back it up (but I can if I want to).

If you move to a different computer where the first had a region-free drive and the new one does not you very much might be unable to regenerate them.
That might be considered a libdvdcss bug.

Post by Rémi Denis-Courmont

Post by Reimar Döffinger
Putting the keys in the cache does not reduce the backup size in any
relevant way, so I simply see no _advantage_ to considering it a cache.

That's hardly relevant. And you are assuming that only a small number of discs
will ever be inserted in a given system. That's not necessarily true (public
library?).

Why is it irrelevant to consider what would cause the least inconvenience to users?
And as said, I believe it would still be a fairly irrelevant size if you managed to insert all DVDs in the whole world.

Post by Rémi Denis-Courmont
And I have read complaints about the lack of privacy associated with the
DVDCSS key cache. Marking its content for backup makes matters worse, rather
than better.

That definitely is a concern. However as far as I can tell that was no consideration at all in the XDG spec, and unless almost everyone decides to put all privacy relevant data in the cache I am not exactly convinced it helps for dvdcss to do so.

Post by Rémi Denis-Courmont

Post by Reimar Döffinger
Though I grant you that with libdvdcss the situation is not as inane as
with libaacs, where you ate basically guaranteed to lose access to your
BluRays if you don't backup your .cache and the only way to get it back is
to buy a new (but not too new) drive or hope someone publishes a new host
key...

Device keys are obviously not cache content, and I guess you mean that MKB,
for practical reasons, should also not be considered as such.
Volume keys are probably cache content though. But that is off-topic.

Device keys can become worthless at any moment (I currently do not have one that works woth my drive, again). MKBs seem near impossible to get (if I know the terms right). Leaving volume keys as the only actually working way.
I would not even remotely consider them cache content. It is one of the few things I need to sync between my computers, which I certainly wouldn't do with anything I would consider a cache.

[Apo Poro]

How about something like this patch? It migrates ~/.dvdcss if it exists to $XDG_DATA_HOME/dvdcss and uses the new location going forward.

[Torben Andresen]

This would be perfect.

Post by Apo Poro
How about something like this patch? It migrates ~/.dvdcss if it exists
to $XDG_DATA_HOME/dvdcss and uses the new location going forward.
------------------------------------------------------------------------
_______________________________________________
libdvdcss-devel mailing list
https://mailman.videolan.org/listinfo/libdvdcss-devel

[Reimar Döffinger]

Post by Apo Poro
How about something like this patch? It migrates ~/.dvdcss if it exists to $XDG_DATA_HOME/dvdcss and uses the new location going forward.

To be honest I don't like the idea of silently renaming things (but others might disagree, it's just my opinion).
Also, it does not seem to handle errors, in case rename fails?
Not really about your patch since the old code did that already did, but what is up with the explicit 0 termination after snprintf?
Or is that a messy way to handle home_pos == PATH_MAX and the strncpy misdesign?
Either way it looks a bit scary to me.

Regards,
Reimar

[Reimar Döffinger]

Post by Apo Poro
How about something like this patch? It migrates ~/.dvdcss if it exists to $XDG_DATA_HOME/dvdcss and uses the new location going forward.

I forgot: I'd also prefer a few && over a 4 deep nested if...

[Apo Poro]

Post by Reimar Döffinger

Post by Apo Poro
How about something like this patch? It migrates ~/.dvdcss if it exists to $XDG_DATA_HOME/dvdcss and uses the new location going forward.

I forgot: I'd also prefer a few && over a 4 deep nested if...

Looks like my last message didn't come through, so resending:

Taking the comments into account, here's an amended patch. This one checks if ~/.dvdcss exists and if so, uses it. If there is no ~/.dvdcss, it goes to $XDG_DATA_HOME/dvdcss or ~/.local/share/dvdcss.

I kept explicit null-termination of psz_buffer to stay consistent with the existing code, but if you don't think it's necessary, can easily get rid of it of course.

[Rémi Denis-Courmont]

Post by Apo Poro
How about something like this patch? It migrates ~/.dvdcss if it exists to
$XDG_DATA_HOME/dvdcss and uses the new location going forward.

The stat() tests are prone to ToCToU issues.

I would just probe both the old and new directories for reading, and stick to
the new one for writing.

[Jean-Baptiste Kempf]

Post by Torben Andresen
please implement the XDG basedir specification
(http://standards.freedesktop.org/basedir-spec/latest/) The benefit will be
an clean $HOME and that will help me and other user to make an Backup just
with the needed folders.

See
https://mailman.videolan.org/pipermail/libdvdcss-devel/2013-February/000840.html
and the biggest objection:
https://mailman.videolan.org/pipermail/libdvdcss-devel/2013-February/000858.html

With my kindest regards,