Sigil/DRM Issues After Update?

[twedigteam]

Hi all,

We're just in the process of tracking this issue down, not sure if it is our InDesign files or a software bug with Sigil. After updating Sigil to the version just released [0.3.0], our ePub exports from InDesign get the following error:

"The creator of this file has encrypted it with DRM. Sigil cannot open such files."

There is no DRM on the file as we have just exported it from ID, and did not receive this error prior to update. I know this was one of the bugs fixed in Sigil (previously just received a crash error when opening protected ePubs), so I'm not sure if there's suddenly an issue with our .indd files or not?

Anyone else encountering this issue with the new version?

[Valloric]

Sigil shows this message when it detects the presence of an "encryption.xml" file in the META-INF folder. This file is placed there only when the creator wants to encrypt the content of his epub. Are you saying that InDesign places an "encryption.xml" file even when the epub is not encrypted? That would be an interesting move by Adobe; extremely stupid, yes, but interesting nonetheless.

I'd like to see that file. Feel free to create an issue on the tracker with the epub attached.

[twedigteam]

So, thanks for the response first off. It definitely is the case that InDesign creates an encryption.xml file within the META-INF folder, even though there shouldn't be any encryption. We are merely taking a raw .indd, exporting, and cleaning up in Sigil...so, very possibly it could then be some of our InDesign files, as older exports we have done still work fine in the new Sigil.

This is the encryption.xml file:

<encryption xmlns="urnasis:names:tcpendocument:xmlns:conta iner" xmlns:enc="http://www.w3.org/2001/04/xmlenc#" xmlns:deenc="http://ns.adobe.com/digitaleditions/enc"><enc:EncryptedData><enc:EncryptionMethod Algorithm="http://ns.adobe.com/pdf/enc#RC"/><enc:CipherData><enc:CipherReference URI="OEBPS/Fonts/AGaramondPro-Regular.otf"/></enc:CipherData></enc:EncryptedData><enc:EncryptedData><enc:Encrypti onMethod Algorithm="http://ns.adobe.com/pdf/enc#RC"/><enc:CipherData><enc:CipherReference URI="OEBPS/Fonts/AGaramondPro-Italic.otf"/></enc:CipherData></enc:EncryptedData></encryption>

[Valloric]

What version of InDesign are you using?

[charleski]

Originally Posted by Valloric

Are you saying that InDesign places an "encryption.xml" file even when the epub is not encrypted?

It will if the ePub has embedded fonts, as is the case here.

The solution is simple - don't embed the fonts.

[Valloric]

Originally Posted by charleski

It will if the ePub has embedded fonts, as is the case here.

The solution is simple - don't embed the fonts.

That is not the correct solution. If InDesign is encrypting the fonts, then that's a problem with InDesign. One can embed fonts in many different ways (hm, let's say Sigil), and not encrypting them is the best option.

twedigteam, you still haven't provided the epub file with which you are having problems. Please do so. There's a "private issue" template on the tracker if you are worried about others having access to the file.

[charleski]

This has been discussed a while ago on the epub forum. inDesign obfuscates the fonts (there's no real encryption) in order to dissuade people from removing them from the epub. It inserts an encryption.xml to signal this fact. This is not the problem, since some font licences require obfuscation. The real problem is that the epub standard specifies a different obfuscation scheme to that used by Adobe (though frankly this is another area in which the standard is just a result of silly political manoeuvring, since they didn't want to adopt the system already developed by Adobe).

The solution is exactly as I stated: don't embed fonts from inDesign and you won't get the encryption file.

I somehow doubt that twedigteam has a licence to distribute Adobe Garamond anyway.

[HarryT]

Originally Posted by Valloric

That is not the correct solution. If InDesign is encrypting the fonts, then that's a problem with InDesign. One can embed fonts in many different ways (hm, let's say Sigil), and not encrypting them is the best option.

A font may be legally embeddable, but not redistributable. I imagine that is why InDesign is encrypting embedded fonts. What can be done other than encryption to prevent a user from simply copying a font out of an ePub file?

[Valloric]

Originally Posted by charleski

This has been discussed a while ago on the epub forum. inDesign obfuscates the fonts (there's no real encryption) in order to dissuade people from removing them from the epub. It inserts an encryption.xml to signal this fact.

I'm aware of the fact that InDesign can do this, I just wasn't aware that it did it by default.

Originally Posted by charleski

This is not the problem, since some font licences require obfuscation.

This is debatable. It is thought that obfuscating a font in the Adobe or IDPF method is enough to placate the foundries, but I've yet to see someone from the foundries confirm that.

Originally Posted by charleski

The real problem is that the epub standard specifies a different obfuscation scheme to that used by Adobe (though frankly this is another area in which the standard is just a result of silly political manoeuvring, since they didn't want to adopt the system already developed by Adobe).

Yes, the IDPF specifies one method and Adobe uses another.

Originally Posted by charleski

The solution is exactly as I stated: don't embed fonts from inDesign and you won't get the encryption file.

You weren't as specific the first time. You just said that the solution was to "not embed the fonts", and not that it was to "not embed the fonts with InDesign". The first one implies a problem with Sigil, and the second one a problem with InDesign.

I was a bit touchy since you appeared to be the third person today to imply that Sigil has problems with embedded fonts, when the root cause is InDesign being brain-dead.

Originally Posted by HarryT

A font may be legally embeddable, but not redistributable. I imagine that is why InDesign is encrypting embedded fonts. What can be done other than encryption to prevent a user from simply copying a font out of an ePub file?

Take a look at the methods I linked to above. A twelve-year-old could write a program to de-obfuscate the fonts that were obfuscated with either method... in about 10 minutes. And the program would only be a few lines of code.

In fact, that's just what I'm about to add to Sigil. A Book Browser right-click context menu for fonts that enable the user to obfuscate or de-obfuscate the font with either method. By default, whatever state the font was in when the epub was opened will be the state in which it will be saved.

[Jellby]

Regardless of what InDesign does, is it really the best option to reject an ePUB file as DRMed just because it contains an "encryption.xml" file? Wouldn't it be better if Sigil could actually determine which files, if any, are encrypted and warn about those?

[Valloric]

Originally Posted by Jellby

Regardless of what InDesign does, is it really the best option to reject an ePUB file as DRMed just because it contains an "encryption.xml" file? Wouldn't it be better if Sigil could actually determine which files, if any, are encrypted and warn about those?

Originally Posted by Valloric

In fact, that's just what I'm about to add to Sigil. A Book Browser right-click context menu for fonts that enable the user to obfuscate or de-obfuscate the font with either method. By default, whatever state the font was in when the epub was opened will be the state in which it will be saved.

There you go. The next version will behave differently. There will be no error displayed since Sigil will support font obfuscation.

[Valloric]

Originally Posted by Valloric

There you go. The next version will behave differently. There will be no error displayed since Sigil will support font obfuscation.

As of revision 85344072a1, the final version of this feature is now implemented.