https://wiki.openoffice.org/w/api.php?action=feedcontributions&feedformat=atom&user=Mav 2026-05-06T04:16:58Z User contributions MediaWiki 1.35.14 https://wiki.openoffice.org/w/index.php?title=Security/Encryption&diff=137962 2009-08-21T12:17:16Z

<p>Mav: /* Enhancing the Encryption Specification for ODF 1.2 */</p> <hr /> <div>== Encrypted documents shouldn&#039;t have any non encrypted content ==<br /> <br /> Currently it is possible to add any non encrypted content into encrypted documents, simply by putting new streams into the zip archive. <br /> <br /> This way, someone could for example add macro code into documents without the need to know the password. <br /> <br /> The possibility to add content to an encrypted document is quite bad, and it becomes worse with macros, because passwords increase the level of trust the user has to a document, when it was encrypted by a person he knows. <br /> <br /> OOo will detect the macros, and ask the user whether or not to execute them. The user might trust the author of the document, and because of the encryption normally nobody should have been able to manipulate it, so he will probably allow OOo to execute the macros. At least, it&#039;s not possible to bind the macros to some event, so it would get executed automatically. <br /> <br /> In general, an encrypted document shouldn&#039;t have any non encrypted content. Exceptions are some files in the META-INF folder: manifest.xml, which is needed to get the encryption information, and the digital signature files also might not be encrypted, depending on the signature implementation. <br /> <br /> OOo should show a warning when an encrypted document contains streams which should be encrypted, but aren&#039;t. Additionally, macros should be disabled for the document. (issue #i103927)<br /> <br /> == Improving the Encryption Implementation in OOo 3.2 ==<br /> <br /> For OOo 3.2, we plan to improve the document encryption, or better, the handling of documents which have issues like mentioned above (issue #i103927). <br /> <br /> When OOo opens an encrypted document, it will check via the manifest if all files are encrypted. Some encrypted files in a ODF zip archive still might use the encryption key, different from the document encryption key.<br /> <br /> When detecting not encrypted files, OOo will show a warning to the user, and will disable the execution of macros in the document.<br /> <br /> == Enhancing the Encryption Specification for ODF 1.2 ==<br /> <br /> Currently the ODF specification specifies one way for encrypting ODF documents, and ODF applications can&#039;t chose different algorithms. &lt;br&gt; <br /> <br /> Choosing other encryption algorithms can be important, to comply with encryption rules from a company or Government using ODF. <br /> <br /> The information about the used algorithms (for each step)&amp;nbsp;need to be documented in the manifest.xml.&lt;br&gt; <br /> <br /> This is the general part of the latest draft of the proposal that we will send to the OASIS OpenDocument TC:&lt;br&gt; <br /> &lt;blockquote&gt;2.3 Encryption: &lt;/blockquote&gt;&lt;blockquote&gt;The encryption process takes place in the following multiple stages:&lt;br&gt; <br /> #The start key is generated and is provided to the package component. <br /> #The derived key is generated by the component based on the start key. <br /> #The files are encrypted based on the derived key and the encryption algorithm.<br /> The implementation must support at least the described below default way for the mentioned steps. In addition it might support encryption, where algorithms different from the default are used for the steps. The information regarding used for each step algorithms has to be provided in the manifest.xml accordingly. &lt;/blockquote&gt;&lt;blockquote&gt;The default way is:&lt;br&gt; <br /> #The start key is generated. The byte sequence representing the password in UTF-8 is used to generate a 20-byte SHA1 digest (see [RFC3174]). The result star key is passed to the package component. <br /> #The derived key is generated by the package component from the start key. The PBKDF2 algorithm based on HMAC-SHA-1 function (see [RFC2898]) is used for the key derivation. The random number generator initialized with the current time is used to generate 16-byte salt for each file. The salt is used together with the start key to derive a unique 128-bit key for each file. The default iteration count for the algorithm is 1024. <br /> #The files are encrypted. The random number generator is used to generate the 8-byte initialization vector for the algorithm. The derived key is used together with the initialization vector to encrypt the file using the Blowfish algorithm in cipher feedback (CFB) mode (see [blowfish]).<br /> Each file that is encrypted is compressed before being encrypted. To allow the contents of the package file to be verified, it is necessary that encrypted files are flagged as &#039;STORED&#039; rather than &#039;DEFLATED&#039;. As entries which are &#039;STORED&#039; must have their size equal to the compressed size, it is necessary to store the uncompressed size in the manifest. The compressed size is stored in both the local file header and central directory record of the Zip file.&lt;br&gt;&lt;/blockquote&gt;<br /> <br /> == Comply to the updated ODF 1.2 Encryption Specification in OOo 3.2 ==<br /> <br /> OOo 3.2 needs to comply with the updated encryption specification above. This mainly means that all algorithms used in the different steps needs to be documented in the manifest.xml. It does not mean that OOo would implement other algorithms now. (issue #XXXXX)<br /> <br /> == Missing Encryption of manifest.xml ==<br /> <br /> To some people it looks surprising that the manifest.xml is not encrypted. <br /> <br /> Actually, the manifest.xml contains the information that any ODF application needs to open the document, including the encryption and hash algorithms which have been used to encrypt the document...<br /> <br /> == Protecting the not encrypted manifest.xml in an encrypted document ==<br /> <br /> Since the manifest.xml can&#039;t be encrypted, someone could make modifications to manifest.xml in encrypted documents. <br /> <br /> It needs to be discussed if there needs to be some protection against this. <br /> <br /> For example, we could generate some signature/hash for encrypted version of manifest.xml ( with the common document encryption key ), and store it in a separate stream in the META-INF folder.<br /> <br /> This could be some OOo-only solution, and OOo would only warn when the signature is missing in documents written with OOo, or it could become part of some future version of the ODF specification. <br /> <br /> This topic needs further discussions...<br /> <br /> == Public Key Document Encryption ==<br /> <br /> It would be a nice feature to allow public key encryption for encrypting documents. People could encrypt the documents with their own and/or with other people&#039;s public key certificates, so only the owners of the corresponding private keys would be able to open the document. No need to exchange or remember passwords. <br /> <br /> == Digital Rights Management ==<br /> <br /> OpenOffice.org could support DRM. The part &quot;user can/can&#039;t open a document&quot; makes sense, can be implemented reliable. Enhanced rights/restrictions like &quot;can copy/print/...&quot; can&#039;t be guaranteed, because they could be removed easily in an open source application. <br /> <br /> See also [http://www.slideshare.net/Malte.Timmermann/openofficeorgstaroffice-drm-omc-workshop-2006-presentation my slides] from Sun&#039;s [http://www.openmediacommons.org/ Open Media Commons] workshop. <br /> <br /> == Password length and password pattern ==<br /> <br /> The ancient minimal password length in the password dialog should be removed, but don&#039;t allow empty passwords. (issue #i103783) <br /> <br /> In future it&#039;s better to add some good explanations about strong passwords to password dialogs and online help.<br /> <br /> What about adding some configuration items, so companies can configure OOo to adhere to their password rules? <br /> <br /> Ooo-password-properties: MinPasswordLength (default=1 if not set), MinNumbercharacters, MinSpecialCharacters, ForbiddenCharacters. <br /> <br /> We would then also need some dialog which explains the password rule to the user.<br /> <br /> == Thumbnails in encrypted documents ==<br /> <br /> ODF documents can contain a thumbnail, to display a small picture of the first page in a file explorer. <br /> <br /> Currently, encrypted documents contain encrypted thumbnails, which is not good for anything.<br /> <br /> Encrypted documents shouldn&#039;t store thumbnails. (issue #i103930)&lt;br&gt;<br /> <br /> The reason for this is that encrypted documents mustn&#039;t contain any non encrypted streams (with some exceptions). And since the encrypted document contains a standard bitmap as a thumbnail it makes no sense to store it in the document anyway. The bitmap should be part of the system integration. <br /> <br /> [[Category:Security]]</div>

Mav https://wiki.openoffice.org/w/index.php?title=Security/Encryption&diff=137961 2009-08-21T12:16:07Z

<p>Mav: /* Enhancing the Encryption Specification for ODF 1.2 */</p> <hr /> <div>== Encrypted documents shouldn&#039;t have any non encrypted content ==<br /> <br /> Currently it is possible to add any non encrypted content into encrypted documents, simply by putting new streams into the zip archive. <br /> <br /> This way, someone could for example add macro code into documents without the need to know the password. <br /> <br /> The possibility to add content to an encrypted document is quite bad, and it becomes worse with macros, because passwords increase the level of trust the user has to a document, when it was encrypted by a person he knows. <br /> <br /> OOo will detect the macros, and ask the user whether or not to execute them. The user might trust the author of the document, and because of the encryption normally nobody should have been able to manipulate it, so he will probably allow OOo to execute the macros. At least, it&#039;s not possible to bind the macros to some event, so it would get executed automatically. <br /> <br /> In general, an encrypted document shouldn&#039;t have any non encrypted content. Exceptions are some files in the META-INF folder: manifest.xml, which is needed to get the encryption information, and the digital signature files also might not be encrypted, depending on the signature implementation. <br /> <br /> OOo should show a warning when an encrypted document contains streams which should be encrypted, but aren&#039;t. Additionally, macros should be disabled for the document. (issue #i103927)<br /> <br /> == Improving the Encryption Implementation in OOo 3.2 ==<br /> <br /> For OOo 3.2, we plan to improve the document encryption, or better, the handling of documents which have issues like mentioned above (issue #i103927). <br /> <br /> When OOo opens an encrypted document, it will check via the manifest if all files are encrypted. Some encrypted files in a ODF zip archive still might use the encryption key, different from the document encryption key.<br /> <br /> When detecting not encrypted files, OOo will show a warning to the user, and will disable the execution of macros in the document.<br /> <br /> == Enhancing the Encryption Specification for ODF 1.2 ==<br /> <br /> Currently the ODF specification specifies one way for encrypting ODF documents, and ODF applications can&#039;t chose different algorithms. &lt;br&gt; <br /> <br /> Choosing other encryption algorithms can be important, to comply with encryption rules from a company or Government using ODF. <br /> <br /> The information about the used algorithms (for each step)&amp;nbsp;need to be documented in the manifest.xml.&lt;br&gt; <br /> <br /> This is the latest draft of the proposal that we will send to the OASIS OpenDocument TC:&lt;br&gt; <br /> &lt;blockquote&gt;2.3 Encryption: &lt;/blockquote&gt;&lt;blockquote&gt;The encryption process takes place in the following multiple stages:&lt;br&gt; <br /> #The start key is generated and is provided to the package component. <br /> #The derived key is generated by the component based on the start key. <br /> #The files are encrypted based on the derived key and the encryption algorithm.<br /> The implementation must support at least the described below default way for the mentioned steps. In addition it might support encryption, where algorithms different from the default are used for the steps. The information regarding used for each step algorithms has to be provided in the manifest.xml accordingly. &lt;/blockquote&gt;&lt;blockquote&gt;The default way is:&lt;br&gt; <br /> #The start key is generated. The byte sequence representing the password in UTF-8 is used to generate a 20-byte SHA1 digest (see [RFC3174]). The result star key is passed to the package component. <br /> #The derived key is generated by the package component from the start key. The PBKDF2 algorithm based on HMAC-SHA-1 function (see [RFC2898]) is used for the key derivation. The random number generator initialized with the current time is used to generate 16-byte salt for each file. The salt is used together with the start key to derive a unique 128-bit key for each file. The default iteration count for the algorithm is 1024. <br /> #The files are encrypted. The random number generator is used to generate the 8-byte initialization vector for the algorithm. The derived key is used together with the initialization vector to encrypt the file using the Blowfish algorithm in cipher feedback (CFB) mode (see [blowfish]).<br /> Each file that is encrypted is compressed before being encrypted. To allow the contents of the package file to be verified, it is necessary that encrypted files are flagged as &#039;STORED&#039; rather than &#039;DEFLATED&#039;. As entries which are &#039;STORED&#039; must have their size equal to the compressed size, it is necessary to store the uncompressed size in the manifest. The compressed size is stored in both the local file header and central directory record of the Zip file.&lt;br&gt;&lt;/blockquote&gt;<br /> <br /> == Comply to the updated ODF 1.2 Encryption Specification in OOo 3.2 ==<br /> <br /> OOo 3.2 needs to comply with the updated encryption specification above. This mainly means that all algorithms used in the different steps needs to be documented in the manifest.xml. It does not mean that OOo would implement other algorithms now. (issue #XXXXX)<br /> <br /> == Missing Encryption of manifest.xml ==<br /> <br /> To some people it looks surprising that the manifest.xml is not encrypted. <br /> <br /> Actually, the manifest.xml contains the information that any ODF application needs to open the document, including the encryption and hash algorithms which have been used to encrypt the document...<br /> <br /> == Protecting the not encrypted manifest.xml in an encrypted document ==<br /> <br /> Since the manifest.xml can&#039;t be encrypted, someone could make modifications to manifest.xml in encrypted documents. <br /> <br /> It needs to be discussed if there needs to be some protection against this. <br /> <br /> For example, we could generate some signature/hash for encrypted version of manifest.xml ( with the common document encryption key ), and store it in a separate stream in the META-INF folder.<br /> <br /> This could be some OOo-only solution, and OOo would only warn when the signature is missing in documents written with OOo, or it could become part of some future version of the ODF specification. <br /> <br /> This topic needs further discussions...<br /> <br /> == Public Key Document Encryption ==<br /> <br /> It would be a nice feature to allow public key encryption for encrypting documents. People could encrypt the documents with their own and/or with other people&#039;s public key certificates, so only the owners of the corresponding private keys would be able to open the document. No need to exchange or remember passwords. <br /> <br /> == Digital Rights Management ==<br /> <br /> OpenOffice.org could support DRM. The part &quot;user can/can&#039;t open a document&quot; makes sense, can be implemented reliable. Enhanced rights/restrictions like &quot;can copy/print/...&quot; can&#039;t be guaranteed, because they could be removed easily in an open source application. <br /> <br /> See also [http://www.slideshare.net/Malte.Timmermann/openofficeorgstaroffice-drm-omc-workshop-2006-presentation my slides] from Sun&#039;s [http://www.openmediacommons.org/ Open Media Commons] workshop. <br /> <br /> == Password length and password pattern ==<br /> <br /> The ancient minimal password length in the password dialog should be removed, but don&#039;t allow empty passwords. (issue #i103783) <br /> <br /> In future it&#039;s better to add some good explanations about strong passwords to password dialogs and online help.<br /> <br /> What about adding some configuration items, so companies can configure OOo to adhere to their password rules? <br /> <br /> Ooo-password-properties: MinPasswordLength (default=1 if not set), MinNumbercharacters, MinSpecialCharacters, ForbiddenCharacters. <br /> <br /> We would then also need some dialog which explains the password rule to the user.<br /> <br /> == Thumbnails in encrypted documents ==<br /> <br /> ODF documents can contain a thumbnail, to display a small picture of the first page in a file explorer. <br /> <br /> Currently, encrypted documents contain encrypted thumbnails, which is not good for anything.<br /> <br /> Encrypted documents shouldn&#039;t store thumbnails. (issue #i103930)&lt;br&gt;<br /> <br /> The reason for this is that encrypted documents mustn&#039;t contain any non encrypted streams (with some exceptions). And since the encrypted document contains a standard bitmap as a thumbnail it makes no sense to store it in the document anyway. The bitmap should be part of the system integration. <br /> <br /> [[Category:Security]]</div>

Mav https://wiki.openoffice.org/w/index.php?title=Security/Encryption&diff=137949 2009-08-21T08:46:31Z

<p>Mav: /* Improving the Encryption Implementation in OOo 3.2 */</p> <hr /> <div>== Encrypted documents shouldn&#039;t have any non encrypted content ==<br /> <br /> Currently it is possible to add any non encrypted content into encrypted documents, simply by putting new streams into the zip archive. <br /> <br /> This way, someone could for example add macro code into documents without the need to know the password. <br /> <br /> The possibility to add content to an encrypted document is quite bad, and it becomes worse with macros, because passwords increase the level of trust the user has to a document, when it was encrypted by a person he knows. <br /> <br /> OOo will detect the macros, and ask the user whether or not to execute them. The user might trust the author of the document, and because of the encryption normally nobody should have been able to manipulate it, so he will probably allow OOo to execute the macros. At least, it&#039;s not possible to bind the macros to some event, so it would get executed automatically. <br /> <br /> In general, an encrypted document shouldn&#039;t have any non encrypted content. Exceptions are some files in the META-INF folder: manifest.xml, which is needed to get the encryption information, and the digital signature files also might not be encrypted, depending on the signature implementation. <br /> <br /> OOo should show a warning when an encrypted document contains streams which should be encrypted, but aren&#039;t. Additionally, macros should be disabled for the document. (issue #i103927)<br /> <br /> == Improving the Encryption Implementation in OOo 3.2 ==<br /> <br /> For OOo 3.2, we plan to improve the document encryption, or better, the handling of documents which have issues like mentioned above (issue #i103927). <br /> <br /> When OOo opens an encrypted document, it will check via the manifest if all files are encrypted. Some encrypted files in a ODF zip archive still might use the encryption key, different from the document encryption key.<br /> <br /> When detecting not encrypted files, OOo will show a warning to the user, and will disable the execution of macros in the document.<br /> <br /> == Enhancing the Encryption Specification for ODF 1.2 ==<br /> <br /> Currently the ODF specification specifies one way for encrypting ODF documents, and ODF applications can&#039;t chose different algorithms. &lt;br&gt; <br /> <br /> Choosing other encryption algorithms can be important, to comply with encryption rules from a company or Government using ODF. <br /> <br /> The information about the used algorithms (for each step)&amp;nbsp;need to be documented in the manifest.xml.&lt;br&gt; <br /> <br /> This is the latest draft of the proposal that we will send to the OASIS OpenDocument TC:&lt;br&gt; <br /> &lt;blockquote&gt;2.3 Encryption: &lt;/blockquote&gt;&lt;blockquote&gt;The encryption process takes place in the following multiple stages:&lt;br&gt; <br /> #The start key is generated and is provided to the package component. <br /> #The derived key is generated by the component based on the start key. <br /> #The files are encrypted based on the derived key and the encryption algorithm.<br /> The implementation must support at least the described below default way for the mentioned steps. In addition it might support encryption, where algorithms different from the default are used for the steps. The information regarding used for each step algorithms has to be provided in the manifest.xml accordingly. &lt;/blockquote&gt;&lt;blockquote&gt;The default way is:&lt;br&gt; <br /> #The start key is generated. The byte sequence representing the password in UTF-8 is used to generate a 20-byte SHA1 digest (see [RFC3174]). The result star key is passed to the package component. <br /> #The derived key is generated by the package component from the start key. The PBKDF2 algorithm based on HMAC-SHA-1 function (see [RFC2898]) is used for the key derivation. The random number generator initialized with the current time is used to generate 16-byte salt for each file. The salt is used together with the start key to derive a unique 128-bit key for each file. The default iteration count for the algorithm is 1024. <br /> #The files are encrypted. The random number generator is used to generate the 8-byte initialization vector for the algorithm. The derived key is used together with the initialization vector to encrypt the file using the Blowfish algorithm in cipher feedback (CFB) mode (see [blowfish]).<br /> Each file that is encrypted is compressed before being encrypted. To allow the contents of the package file to be verified, it is necessary that encrypted files are flagged as &#039;STORED&#039; rather than &#039;DEFLATED&#039;. As entries which are &#039;STORED&#039; must have their size equal to the compressed size, it is necessary to store the uncompressed size in the manifest. The compressed size is stored in both the local file header and central directory record of the Zip file.&lt;br&gt;In an encrypted document all the document files should be encrypted. Non-document files, that are allowed to stay nonencrypted are the files that are recognized as a part of the package format: “mimetype”, “META-INF/manifest.xml” and the signature streams in “META-INF”.&lt;br&gt;&lt;/blockquote&gt;<br /> <br /> == Comply to the updated ODF 1.2 Encryption Specification in OOo 3.2 ==<br /> <br /> OOo 3.2 needs to comply with the updated encryption specification above. This mainly means that all algorithms used in the different steps needs to be documented in the manifest.xml. It does not mean that OOo would implement other algorithms now. (issue #XXXXX)<br /> <br /> == Missing Encryption of manifest.xml ==<br /> <br /> To some people it looks surprising that the manifest.xml is not encrypted. <br /> <br /> Actually, the manifest.xml contains the information that any ODF application needs to open the document, including the encryption and hash algorithms which have been used to encrypt the document...<br /> <br /> == Protecting the not encrypted manifest.xml in an encrypted document ==<br /> <br /> Since the manifest.xml can&#039;t be encrypted, someone could make modifications to manifest.xml in encrypted documents. <br /> <br /> It needs to be discussed if there needs to be some protection against this. <br /> <br /> For example, we could generate some signature/hash for encrypted version of manifest.xml ( with the common document encryption key ), and store it in a separate stream in the META-INF folder.<br /> <br /> This could be some OOo-only solution, and OOo would only warn when the signature is missing in documents written with OOo, or it could become part of some future version of the ODF specification. <br /> <br /> This topic needs further discussions...<br /> <br /> == Public Key Document Encryption ==<br /> <br /> It would be a nice feature to allow public key encryption for encrypting documents. People could encrypt the documents with their own and/or with other people&#039;s public key certificates, so only the owners of the corresponding private keys would be able to open the document. No need to exchange or remember passwords. <br /> <br /> == Digital Rights Management ==<br /> <br /> OpenOffice.org could support DRM. The part &quot;user can/can&#039;t open a document&quot; makes sense, can be implemented reliable. Enhanced rights/restrictions like &quot;can copy/print/...&quot; can&#039;t be guaranteed, because they could be removed easily in an open source application. <br /> <br /> See also [http://www.slideshare.net/Malte.Timmermann/openofficeorgstaroffice-drm-omc-workshop-2006-presentation my slides] from Sun&#039;s [http://www.openmediacommons.org/ Open Media Commons] workshop. <br /> <br /> == Password length and password pattern ==<br /> <br /> The ancient minimal password length in the password dialog should be removed, but don&#039;t allow empty passwords. (issue #i103783) <br /> <br /> In future it&#039;s better to add some good explanations about strong passwords to password dialogs and online help.<br /> <br /> What about adding some configuration items, so companies can configure OOo to adhere to their password rules? <br /> <br /> Ooo-password-properties: MinPasswordLength (default=1 if not set), MinNumbercharacters, MinSpecialCharacters, ForbiddenCharacters. <br /> <br /> We would then also need some dialog which explains the password rule to the user.<br /> <br /> == Thumbnails in encrypted documents ==<br /> <br /> ODF documents can contain a thumbnail, to display a small picture of the first page in a file explorer. <br /> <br /> Currently, encrypted documents contain encrypted thumbnails, which is not good for anything.<br /> <br /> Encrypted documents shouldn&#039;t store thumbnails. (issue #i103930)&lt;br&gt;<br /> <br /> The reason for this is that encrypted documents mustn&#039;t contain any non encrypted streams (with some exceptions). And since the encrypted document contains a standard bitmap as a thumbnail it makes no sense to store it in the document anyway. The bitmap should be part of the system integration. <br /> <br /> [[Category:Security]]</div>

Mav https://wiki.openoffice.org/w/index.php?title=Security/Document_Integrity&diff=137948 2009-08-21T08:35:45Z

<p>Mav: /* Make sure OOo 3.2 would adhere to the ODF conformance clause */</p> <hr /> <div>The best way to ensure document integrity is to digitally sign the documents. <br /> <br /> But most people won&#039;t do it, or even don&#039;t have the infrastructure for this, so there should be some light weight mechanism for checking the document integrity <br /> <br /> == ODF conformance clause ==<br /> <br /> The ODF specification should have some conformance clause, that all files, except package meta data in META-INF folder (signature streams for example) and the mimetype stream, must be registered in manifest.xml. <br /> <br /> With the current ODF&amp;nbsp;specification, the META-INF&amp;nbsp;folder should only contain manifest.xml, and might contain some signature streams (*signatures.xml).<br /> <br /> When this is defined, an ODF application should not load any files which are not registered in manifest, or show a warning to the user.<br /> <br /> == Make sure OOo 3.2 would adhere to the ODF conformance clause ==<br /> <br /> Independently from whether or not the conformance clause above will make it into the ODF specification, OpenOffice.org should create documents adhering to the definition above. That should be already the case in OOo3.1 except the signature stream that is still registered in manifest.xml. That will be changed for OOo3.2 ( issue #i103989 )<br /> <br /> == Check ODF integrity in OOo 3.2 ==<br /> <br /> Assuming that the conformance clause above will be added to the ODF specification, OOo should warn when loading documents containing streams not registered in manifest.xml.(issue #i104389)&lt;br&gt; <br /> <br /> The check/warning is not necessary when the document has a broken signature.<br /> <br /> This shouldn&#039;t be a problem for older documents (written with OOo), because OOo is already registering all files in manifest.xml <br /> <br /> Maybe the check should only be done for ODF&amp;nbsp;1.2 (and newer)&amp;nbsp;documents, to avoid interop problems with documents written by other applications.</div>

Mav https://wiki.openoffice.org/w/index.php?title=Security/Document_Integrity&diff=137946 2009-08-21T08:30:11Z

<p>Mav: /* Check ODF integrity in OOo 3.2 */</p> <hr /> <div>The best way to ensure document integrity is to digitally sign the documents. <br /> <br /> But most people won&#039;t do it, or even don&#039;t have the infrastructure for this, so there should be some light weight mechanism for checking the document integrity <br /> <br /> == ODF conformance clause ==<br /> <br /> The ODF specification should have some conformance clause, that all files, except package meta data in META-INF folder (signature streams for example) and the mimetype stream, must be registered in manifest.xml. <br /> <br /> With the current ODF&amp;nbsp;specification, the META-INF&amp;nbsp;folder should only contain manifest.xml, and might contain some signature streams (*signatures.xml).<br /> <br /> When this is defined, an ODF application should not load any files which are not registered in manifest, or show a warning to the user.<br /> <br /> == Make sure OOo 3.2 would adhere to the ODF conformance clause ==<br /> <br /> Independently from whether or not the conformance clause above will make it into the ODF specification, OpenOffice.org should create documents adhering to the definition above. (isse #XXXXX)<br /> <br /> == Check ODF integrity in OOo 3.2 ==<br /> <br /> Assuming that the conformance clause above will be added to the ODF specification, OOo should warn when loading documents containing streams not registered in manifest.xml.(issue #i104389)&lt;br&gt; <br /> <br /> The check/warning is not necessary when the document has a broken signature.<br /> <br /> This shouldn&#039;t be a problem for older documents (written with OOo), because OOo is already registering all files in manifest.xml <br /> <br /> Maybe the check should only be done for ODF&amp;nbsp;1.2 (and newer)&amp;nbsp;documents, to avoid interop problems with documents written by other applications.</div>

Mav https://wiki.openoffice.org/w/index.php?title=Security/Encryption&diff=137754 2009-08-19T11:38:44Z

<p>Mav: /* Improving the Encryption Implementation in OOo 3.2 */</p> <hr /> <div>== Encrypted documents shouldn&#039;t have any non encrypted content ==<br /> <br /> Currently it is possible to add any non encrypted content into encrypted documents, simply by putting new streams into the zip archive. <br /> <br /> This way, someone could for example add macro code into documents without the need to know the password. <br /> <br /> The possibility to add content to an encrypted document is quite bad, and it becomes worse with macros, because passwords increase the level of trust the user has to a document, when it was encrypted by a person he knows. <br /> <br /> OOo will detect the macros, and ask the user whether or not to execute them. The user might trust the author of the document, and because of the encryption normally nobody should have been able to manipulate it, so he will probably allow OOo to execute the macros. At least, it&#039;s not possible to bind the macros to some event, so it would get executed automatically. <br /> <br /> In general, an encrypted document shouldn&#039;t have any non encrypted content. Exceptions are some files in the META-INF folder: manifest.xml, which is needed to get the encryption information, and the digital signature files also might not be encrypted, depending on the signature implementation. <br /> <br /> OOo should show a warning when an encrypted document contains streams which should be encrypted, but aren&#039;t. Additionally, macros should be disabled for the document. (issue #i103927)<br /> <br /> == Improving the Encryption Implementation in OOo 3.2 ==<br /> <br /> For OOo 3.2, we plan to improve the document encryption, or better, the handling of documents which have issues like mentioned above (issue #i103927). <br /> <br /> When OOo opens an encrypted document, it will check via the manifest if all files are encrypted. All encrypted files in a ODF zip archive must use the same encryption key. It is also necessary to check the actual file content, and not the manifest alone. This could be done on access, or in a background process for all files. When detecting not encrypted files, OOo will show a warning to the user, and will not execute any unencrypted macros in encrypted documents.<br /> <br /> The encrypted library-streams have to be encrypted using the container document encryption to let the container document comply with the mentioned above rule. ( issue #i104334 )<br /> <br /> == Enhancing the Encryption Specification for ODF 1.2 ==<br /> <br /> Currently the ODF specification specifies one way for encrypting ODF documents, and ODF applications can&#039;t chose different algorithms. &lt;br&gt; <br /> <br /> Choosing other encryption algorithms can be important, to comply with encryption rules from a company or Government using ODF. <br /> <br /> The information about the used algorithms (for each step)&amp;nbsp;need to be documented in the manifest.xml.&lt;br&gt; <br /> <br /> This is the latest draft of the proposal that we will send to the OASIS OpenDocument TC:&lt;br&gt; <br /> &lt;blockquote&gt;2.3 Encryption: &lt;/blockquote&gt;&lt;blockquote&gt;The encryption process takes place in the following multiple stages:&lt;br&gt; <br /> #The start key is generated and is provided to the package component. <br /> #The derived key is generated by the component based on the start key. <br /> #The files are encrypted based on the derived key and the encryption algorithm.<br /> The implementation must support at least the described below default way for the mentioned steps. In addition it might support encryption, where algorithms different from the default are used for the steps. The information regarding used for each step algorithms has to be provided in the manifest.xml accordingly. &lt;/blockquote&gt;&lt;blockquote&gt;The default way is:&lt;br&gt; <br /> #The start key is generated. The byte sequence representing the password in UTF-8 is used to generate a 20-byte SHA1 digest (see [RFC3174]). The result star key is passed to the package component. <br /> #The derived key is generated by the package component from the start key. The PBKDF2 algorithm based on HMAC-SHA-1 function (see [RFC2898]) is used for the key derivation. The random number generator initialized with the current time is used to generate 16-byte salt for each file. The salt is used together with the start key to derive a unique 128-bit key for each file. The default iteration count for the algorithm is 1024. <br /> #The files are encrypted. The random number generator is used to generate the 8-byte initialization vector for the algorithm. The derived key is used together with the initialization vector to encrypt the file using the Blowfish algorithm in cipher feedback (CFB) mode (see [blowfish]).<br /> Each file that is encrypted is compressed before being encrypted. To allow the contents of the package file to be verified, it is necessary that encrypted files are flagged as &#039;STORED&#039; rather than &#039;DEFLATED&#039;. As entries which are &#039;STORED&#039; must have their size equal to the compressed size, it is necessary to store the uncompressed size in the manifest. The compressed size is stored in both the local file header and central directory record of the Zip file.&lt;br&gt;In an encrypted document all the document files should be encrypted. Non-document files, that are allowed to stay nonencrypted are the files that are recognized as a part of the package format: “mimetype”, “META-INF/manifest.xml” and the signature streams in “META-INF”.&lt;br&gt;&lt;/blockquote&gt;<br /> <br /> == Comply to the updated ODF 1.2 Encryption Specification in OOo 3.2 ==<br /> <br /> OOo 3.2 needs to comply with the updated encryption specification above. This mainly means that all algorithms used in the different steps needs to be documented in the manifest.xml. It does not mean that OOo would implement other algorithms now. (issue #XXXXX)<br /> <br /> == Missing Encryption of manifest.xml ==<br /> <br /> To some people it looks surprising that the manifest.xml is not encrypted. <br /> <br /> Actually, the manifest.xml contains the information that any ODF application needs to open the document, including the encryption and hash algorithms which have been used to encrypt the document...<br /> <br /> == Protecting the not encrypted manifest.xml in an encrypted document ==<br /> <br /> Since the manifest.xml can&#039;t be encrypted, someone could make modifications to manifest.xml in encrypted documents. <br /> <br /> It needs to be discussed if there needs to be some protection against this. <br /> <br /> For example, we could generate some signature/hash for encrypted version of manifest.xml ( with the common document encryption key ), and store it in a separate stream in the META-INF folder.<br /> <br /> This could be some OOo-only solution, and OOo would only warn when the signature is missing in documents written with OOo, or it could become part of some future version of the ODF specification. <br /> <br /> This topic needs further discussions...<br /> <br /> == Public Key Document Encryption ==<br /> <br /> It would be a nice feature to allow public key encryption for encrypting documents. People could encrypt the documents with their own and/or with other people&#039;s public key certificates, so only the owners of the corresponding private keys would be able to open the document. No need to exchange or remember passwords. <br /> <br /> == Digital Rights Management ==<br /> <br /> OpenOffice.org could support DRM. The part &quot;user can/can&#039;t open a document&quot; makes sense, can be implemented reliable. Enhanced rights/restrictions like &quot;can copy/print/...&quot; can&#039;t be guaranteed, because they could be removed easily in an open source application. <br /> <br /> See also [http://www.slideshare.net/Malte.Timmermann/openofficeorgstaroffice-drm-omc-workshop-2006-presentation my slides] from Sun&#039;s [http://www.openmediacommons.org/ Open Media Commons] workshop. <br /> <br /> == Password length and password pattern ==<br /> <br /> The ancient minimal password length in the password dialog should be removed, but don&#039;t allow empty passwords. (issue #i103783) <br /> <br /> In future it&#039;s better to add some good explanations about strong passwords to password dialogs and online help.<br /> <br /> What about adding some configuration items, so companies can configure OOo to adhere to their password rules? <br /> <br /> Ooo-password-properties: MinPasswordLength (default=1 if not set), MinNumbercharacters, MinSpecialCharacters, ForbiddenCharacters. <br /> <br /> We would then also need some dialog which explains the password rule to the user.<br /> <br /> == Thumbnails in encrypted documents ==<br /> <br /> ODF documents can contain a thumbnail, to display a small picture of the first page in a file explorer. <br /> <br /> Currently, encrypted documents contain encrypted thumbnails, which is not good for anything.<br /> <br /> Encrypted documents shouldn&#039;t store thumbnails. (issue #i103930)&lt;br&gt;<br /> <br /> The reason for this is that encrypted documents mustn&#039;t contain any non encrypted streams (with some exceptions). And since the encrypted document contains a standard bitmap as a thumbnail it makes no sense to store it in the document anyway. The bitmap should be part of the system integration. <br /> <br /> [[Category:Security]]</div>

Mav https://wiki.openoffice.org/w/index.php?title=Security/Encryption&diff=137753 2009-08-19T11:19:59Z

<p>Mav: /* Encrypted documents shouldn&#039;t have any non encrypted content */</p> <hr /> <div>== Encrypted documents shouldn&#039;t have any non encrypted content ==<br /> <br /> Currently it is possible to add any non encrypted content into encrypted documents, simply by putting new streams into the zip archive. <br /> <br /> This way, someone could for example add macro code into documents without the need to know the password. <br /> <br /> The possibility to add content to an encrypted document is quite bad, and it becomes worse with macros, because passwords increase the level of trust the user has to a document, when it was encrypted by a person he knows. <br /> <br /> OOo will detect the macros, and ask the user whether or not to execute them. The user might trust the author of the document, and because of the encryption normally nobody should have been able to manipulate it, so he will probably allow OOo to execute the macros. At least, it&#039;s not possible to bind the macros to some event, so it would get executed automatically. <br /> <br /> In general, an encrypted document shouldn&#039;t have any non encrypted content. Exceptions are some files in the META-INF folder: manifest.xml, which is needed to get the encryption information, and the digital signature files also might not be encrypted, depending on the signature implementation. <br /> <br /> OOo should show a warning when an encrypted document contains streams which should be encrypted, but aren&#039;t. Additionally, macros should be disabled for the document. (issue #i103927)<br /> <br /> == Improving the Encryption Implementation in OOo 3.2 ==<br /> <br /> For OOo 3.2, we plan to improve the document encryption, or better, the handling of documents which have issues like mentioned above (issue #i103927). <br /> <br /> When OOo opens an encrypted document, it will check via the manifest if all files are encrypted. All encrypted files in a ODF zip archive must use the same encryption key. It is also necessary to check the actual file content, and not the manifest alone. This could be done on access, or in a background process for all files. When detecting not encrypted files, OOo will show a warning to the user, and will not execute any unencrypted macros in encrypted documents.<br /> <br /> == Enhancing the Encryption Specification for ODF 1.2 ==<br /> <br /> Currently the ODF specification specifies one way for encrypting ODF documents, and ODF applications can&#039;t chose different algorithms. &lt;br&gt; <br /> <br /> Choosing other encryption algorithms can be important, to comply with encryption rules from a company or Government using ODF. <br /> <br /> The information about the used algorithms (for each step)&amp;nbsp;need to be documented in the manifest.xml.&lt;br&gt; <br /> <br /> This is the latest draft of the proposal that we will send to the OASIS OpenDocument TC:&lt;br&gt; <br /> &lt;blockquote&gt;2.3 Encryption: &lt;/blockquote&gt;&lt;blockquote&gt;The encryption process takes place in the following multiple stages:&lt;br&gt; <br /> #The start key is generated and is provided to the package component. <br /> #The derived key is generated by the component based on the start key. <br /> #The files are encrypted based on the derived key and the encryption algorithm.<br /> The implementation must support at least the described below default way for the mentioned steps. In addition it might support encryption, where algorithms different from the default are used for the steps. The information regarding used for each step algorithms has to be provided in the manifest.xml accordingly. &lt;/blockquote&gt;&lt;blockquote&gt;The default way is:&lt;br&gt; <br /> #The start key is generated. The byte sequence representing the password in UTF-8 is used to generate a 20-byte SHA1 digest (see [RFC3174]). The result star key is passed to the package component. <br /> #The derived key is generated by the package component from the start key. The PBKDF2 algorithm based on HMAC-SHA-1 function (see [RFC2898]) is used for the key derivation. The random number generator initialized with the current time is used to generate 16-byte salt for each file. The salt is used together with the start key to derive a unique 128-bit key for each file. The default iteration count for the algorithm is 1024. <br /> #The files are encrypted. The random number generator is used to generate the 8-byte initialization vector for the algorithm. The derived key is used together with the initialization vector to encrypt the file using the Blowfish algorithm in cipher feedback (CFB) mode (see [blowfish]).<br /> Each file that is encrypted is compressed before being encrypted. To allow the contents of the package file to be verified, it is necessary that encrypted files are flagged as &#039;STORED&#039; rather than &#039;DEFLATED&#039;. As entries which are &#039;STORED&#039; must have their size equal to the compressed size, it is necessary to store the uncompressed size in the manifest. The compressed size is stored in both the local file header and central directory record of the Zip file.&lt;br&gt;In an encrypted document all the document files should be encrypted. Non-document files, that are allowed to stay nonencrypted are the files that are recognized as a part of the package format: “mimetype”, “META-INF/manifest.xml” and the signature streams in “META-INF”.&lt;br&gt;&lt;/blockquote&gt;<br /> <br /> == Comply to the updated ODF 1.2 Encryption Specification in OOo 3.2 ==<br /> <br /> OOo 3.2 needs to comply with the updated encryption specification above. This mainly means that all algorithms used in the different steps needs to be documented in the manifest.xml. It does not mean that OOo would implement other algorithms now. (issue #XXXXX)<br /> <br /> == Missing Encryption of manifest.xml ==<br /> <br /> To some people it looks surprising that the manifest.xml is not encrypted. <br /> <br /> Actually, the manifest.xml contains the information that any ODF application needs to open the document, including the encryption and hash algorithms which have been used to encrypt the document...<br /> <br /> == Protecting the not encrypted manifest.xml in an encrypted document ==<br /> <br /> Since the manifest.xml can&#039;t be encrypted, someone could make modifications to manifest.xml in encrypted documents. <br /> <br /> It needs to be discussed if there needs to be some protection against this. <br /> <br /> For example, we could generate some signature/hash for encrypted version of manifest.xml ( with the common document encryption key ), and store it in a separate stream in the META-INF folder.<br /> <br /> This could be some OOo-only solution, and OOo would only warn when the signature is missing in documents written with OOo, or it could become part of some future version of the ODF specification. <br /> <br /> This topic needs further discussions...<br /> <br /> == Public Key Document Encryption ==<br /> <br /> It would be a nice feature to allow public key encryption for encrypting documents. People could encrypt the documents with their own and/or with other people&#039;s public key certificates, so only the owners of the corresponding private keys would be able to open the document. No need to exchange or remember passwords. <br /> <br /> == Digital Rights Management ==<br /> <br /> OpenOffice.org could support DRM. The part &quot;user can/can&#039;t open a document&quot; makes sense, can be implemented reliable. Enhanced rights/restrictions like &quot;can copy/print/...&quot; can&#039;t be guaranteed, because they could be removed easily in an open source application. <br /> <br /> See also [http://www.slideshare.net/Malte.Timmermann/openofficeorgstaroffice-drm-omc-workshop-2006-presentation my slides] from Sun&#039;s [http://www.openmediacommons.org/ Open Media Commons] workshop. <br /> <br /> == Password length and password pattern ==<br /> <br /> The ancient minimal password length in the password dialog should be removed, but don&#039;t allow empty passwords. (issue #i103783) <br /> <br /> In future it&#039;s better to add some good explanations about strong passwords to password dialogs and online help.<br /> <br /> What about adding some configuration items, so companies can configure OOo to adhere to their password rules? <br /> <br /> Ooo-password-properties: MinPasswordLength (default=1 if not set), MinNumbercharacters, MinSpecialCharacters, ForbiddenCharacters. <br /> <br /> We would then also need some dialog which explains the password rule to the user.<br /> <br /> == Thumbnails in encrypted documents ==<br /> <br /> ODF documents can contain a thumbnail, to display a small picture of the first page in a file explorer. <br /> <br /> Currently, encrypted documents contain encrypted thumbnails, which is not good for anything.<br /> <br /> Encrypted documents shouldn&#039;t store thumbnails. (issue #i103930)&lt;br&gt;<br /> <br /> The reason for this is that encrypted documents mustn&#039;t contain any non encrypted streams (with some exceptions). And since the encrypted document contains a standard bitmap as a thumbnail it makes no sense to store it in the document anyway. The bitmap should be part of the system integration. <br /> <br /> [[Category:Security]]</div>

Mav https://wiki.openoffice.org/w/index.php?title=Security/Encryption&diff=137752 2009-08-19T11:19:41Z

<p>Mav: /* Improving the Encryption Implementation in OOo 3.2 */</p> <hr /> <div>== Encrypted documents shouldn&#039;t have any non encrypted content ==<br /> <br /> Currently it is possible to add any non encrypted content into encrypted documents, simply by putting new streams into the zip archive. <br /> <br /> This way, someone could for example add macro code into documents without the need to know the password. <br /> <br /> The possibility to add content to an encrypted document is quite bad, and it becomes worse with macros, because passwords increase the level of trust the user has to a document, when it was encrypted by a person he knows. <br /> <br /> OOo will detect the macros, and ask the user whether or not to execute them. The user might trust the author of the document, and because of the encryption normally nobody should have been able to manipulate it, so he will probably allow OOo to execute the macros. At least, it&#039;s not possible to bind the macros to some event, so it would get executed automatically. <br /> <br /> In general, an encrypted document shouldn&#039;t have any non encrypted content. Exceptions are some files in the META-INF folder: manifest.xml, which is needed to get the encryption information, and the digital signature files also might not be encrypted, depending on the signature implementation. <br /> <br /> OOo should show a warning when an encrypted document contains streams which should be encrypted, but aren&#039;t. Additionally, macros should be disabled for the document. (issue #XXXXX)<br /> <br /> == Improving the Encryption Implementation in OOo 3.2 ==<br /> <br /> For OOo 3.2, we plan to improve the document encryption, or better, the handling of documents which have issues like mentioned above (issue #i103927). <br /> <br /> When OOo opens an encrypted document, it will check via the manifest if all files are encrypted. All encrypted files in a ODF zip archive must use the same encryption key. It is also necessary to check the actual file content, and not the manifest alone. This could be done on access, or in a background process for all files. When detecting not encrypted files, OOo will show a warning to the user, and will not execute any unencrypted macros in encrypted documents.<br /> <br /> == Enhancing the Encryption Specification for ODF 1.2 ==<br /> <br /> Currently the ODF specification specifies one way for encrypting ODF documents, and ODF applications can&#039;t chose different algorithms. &lt;br&gt; <br /> <br /> Choosing other encryption algorithms can be important, to comply with encryption rules from a company or Government using ODF. <br /> <br /> The information about the used algorithms (for each step)&amp;nbsp;need to be documented in the manifest.xml.&lt;br&gt; <br /> <br /> This is the latest draft of the proposal that we will send to the OASIS OpenDocument TC:&lt;br&gt; <br /> &lt;blockquote&gt;2.3 Encryption: &lt;/blockquote&gt;&lt;blockquote&gt;The encryption process takes place in the following multiple stages:&lt;br&gt; <br /> #The start key is generated and is provided to the package component. <br /> #The derived key is generated by the component based on the start key. <br /> #The files are encrypted based on the derived key and the encryption algorithm.<br /> The implementation must support at least the described below default way for the mentioned steps. In addition it might support encryption, where algorithms different from the default are used for the steps. The information regarding used for each step algorithms has to be provided in the manifest.xml accordingly. &lt;/blockquote&gt;&lt;blockquote&gt;The default way is:&lt;br&gt; <br /> #The start key is generated. The byte sequence representing the password in UTF-8 is used to generate a 20-byte SHA1 digest (see [RFC3174]). The result star key is passed to the package component. <br /> #The derived key is generated by the package component from the start key. The PBKDF2 algorithm based on HMAC-SHA-1 function (see [RFC2898]) is used for the key derivation. The random number generator initialized with the current time is used to generate 16-byte salt for each file. The salt is used together with the start key to derive a unique 128-bit key for each file. The default iteration count for the algorithm is 1024. <br /> #The files are encrypted. The random number generator is used to generate the 8-byte initialization vector for the algorithm. The derived key is used together with the initialization vector to encrypt the file using the Blowfish algorithm in cipher feedback (CFB) mode (see [blowfish]).<br /> Each file that is encrypted is compressed before being encrypted. To allow the contents of the package file to be verified, it is necessary that encrypted files are flagged as &#039;STORED&#039; rather than &#039;DEFLATED&#039;. As entries which are &#039;STORED&#039; must have their size equal to the compressed size, it is necessary to store the uncompressed size in the manifest. The compressed size is stored in both the local file header and central directory record of the Zip file.&lt;br&gt;In an encrypted document all the document files should be encrypted. Non-document files, that are allowed to stay nonencrypted are the files that are recognized as a part of the package format: “mimetype”, “META-INF/manifest.xml” and the signature streams in “META-INF”.&lt;br&gt;&lt;/blockquote&gt;<br /> <br /> == Comply to the updated ODF 1.2 Encryption Specification in OOo 3.2 ==<br /> <br /> OOo 3.2 needs to comply with the updated encryption specification above. This mainly means that all algorithms used in the different steps needs to be documented in the manifest.xml. It does not mean that OOo would implement other algorithms now. (issue #XXXXX)<br /> <br /> == Missing Encryption of manifest.xml ==<br /> <br /> To some people it looks surprising that the manifest.xml is not encrypted. <br /> <br /> Actually, the manifest.xml contains the information that any ODF application needs to open the document, including the encryption and hash algorithms which have been used to encrypt the document...<br /> <br /> == Protecting the not encrypted manifest.xml in an encrypted document ==<br /> <br /> Since the manifest.xml can&#039;t be encrypted, someone could make modifications to manifest.xml in encrypted documents. <br /> <br /> It needs to be discussed if there needs to be some protection against this. <br /> <br /> For example, we could generate some signature/hash for encrypted version of manifest.xml ( with the common document encryption key ), and store it in a separate stream in the META-INF folder.<br /> <br /> This could be some OOo-only solution, and OOo would only warn when the signature is missing in documents written with OOo, or it could become part of some future version of the ODF specification. <br /> <br /> This topic needs further discussions...<br /> <br /> == Public Key Document Encryption ==<br /> <br /> It would be a nice feature to allow public key encryption for encrypting documents. People could encrypt the documents with their own and/or with other people&#039;s public key certificates, so only the owners of the corresponding private keys would be able to open the document. No need to exchange or remember passwords. <br /> <br /> == Digital Rights Management ==<br /> <br /> OpenOffice.org could support DRM. The part &quot;user can/can&#039;t open a document&quot; makes sense, can be implemented reliable. Enhanced rights/restrictions like &quot;can copy/print/...&quot; can&#039;t be guaranteed, because they could be removed easily in an open source application. <br /> <br /> See also [http://www.slideshare.net/Malte.Timmermann/openofficeorgstaroffice-drm-omc-workshop-2006-presentation my slides] from Sun&#039;s [http://www.openmediacommons.org/ Open Media Commons] workshop. <br /> <br /> == Password length and password pattern ==<br /> <br /> The ancient minimal password length in the password dialog should be removed, but don&#039;t allow empty passwords. (issue #i103783) <br /> <br /> In future it&#039;s better to add some good explanations about strong passwords to password dialogs and online help.<br /> <br /> What about adding some configuration items, so companies can configure OOo to adhere to their password rules? <br /> <br /> Ooo-password-properties: MinPasswordLength (default=1 if not set), MinNumbercharacters, MinSpecialCharacters, ForbiddenCharacters. <br /> <br /> We would then also need some dialog which explains the password rule to the user.<br /> <br /> == Thumbnails in encrypted documents ==<br /> <br /> ODF documents can contain a thumbnail, to display a small picture of the first page in a file explorer. <br /> <br /> Currently, encrypted documents contain encrypted thumbnails, which is not good for anything.<br /> <br /> Encrypted documents shouldn&#039;t store thumbnails. (issue #i103930)&lt;br&gt;<br /> <br /> The reason for this is that encrypted documents mustn&#039;t contain any non encrypted streams (with some exceptions). And since the encrypted document contains a standard bitmap as a thumbnail it makes no sense to store it in the document anyway. The bitmap should be part of the system integration. <br /> <br /> [[Category:Security]]</div>

Mav https://wiki.openoffice.org/w/index.php?title=Security/Encryption&diff=137751 2009-08-19T11:10:40Z

<p>Mav: /* Protecting the not encrypted manifest.xml in an encrypted document */</p> <hr /> <div>== Encrypted documents shouldn&#039;t have any non encrypted content ==<br /> <br /> Currently it is possible to add any non encrypted content into encrypted documents, simply by putting new streams into the zip archive. <br /> <br /> This way, someone could for example add macro code into documents without the need to know the password. <br /> <br /> The possibility to add content to an encrypted document is quite bad, and it becomes worse with macros, because passwords increase the level of trust the user has to a document, when it was encrypted by a person he knows. <br /> <br /> OOo will detect the macros, and ask the user whether or not to execute them. The user might trust the author of the document, and because of the encryption normally nobody should have been able to manipulate it, so he will probably allow OOo to execute the macros. At least, it&#039;s not possible to bind the macros to some event, so it would get executed automatically. <br /> <br /> In general, an encrypted document shouldn&#039;t have any non encrypted content. Exceptions are some files in the META-INF folder: manifest.xml, which is needed to get the encryption information, and the digital signature files also might not be encrypted, depending on the signature implementation. <br /> <br /> OOo should show a warning when an encrypted document contains streams which should be encrypted, but aren&#039;t. Additionally, macros should be disabled for the document. (issue #XXXXX)<br /> <br /> == Improving the Encryption Implementation in OOo 3.2 ==<br /> <br /> For OOo 3.2, we plan to improve the document encryption, or better, the handling of documents which have issues like mentioned above (issue #XXXXX). <br /> <br /> When OOo opens an encrypted document, it will check via the manifest if all files are encrypted. All encrypted files in a ODF zip archive must use the same encryption key. It is also necessary to check the actual file content, and not the manifest alone. This could be done on access, or in a background process for all files. When detecting not encrypted files, OOo will show a warning to the user, and will not execute any unencrypted macros in encrypted documents. <br /> <br /> == Enhancing the Encryption Specification for ODF 1.2 ==<br /> <br /> Currently the ODF specification specifies one way for encrypting ODF documents, and ODF applications can&#039;t chose different algorithms. &lt;br&gt; <br /> <br /> Choosing other encryption algorithms can be important, to comply with encryption rules from a company or Government using ODF. <br /> <br /> The information about the used algorithms (for each step)&amp;nbsp;need to be documented in the manifest.xml.&lt;br&gt; <br /> <br /> This is the latest draft of the proposal that we will send to the OASIS OpenDocument TC:&lt;br&gt; <br /> &lt;blockquote&gt;2.3 Encryption: &lt;/blockquote&gt;&lt;blockquote&gt;The encryption process takes place in the following multiple stages:&lt;br&gt; <br /> #The start key is generated and is provided to the package component. <br /> #The derived key is generated by the component based on the start key. <br /> #The files are encrypted based on the derived key and the encryption algorithm.<br /> The implementation must support at least the described below default way for the mentioned steps. In addition it might support encryption, where algorithms different from the default are used for the steps. The information regarding used for each step algorithms has to be provided in the manifest.xml accordingly. &lt;/blockquote&gt;&lt;blockquote&gt;The default way is:&lt;br&gt; <br /> #The start key is generated. The byte sequence representing the password in UTF-8 is used to generate a 20-byte SHA1 digest (see [RFC3174]). The result star key is passed to the package component. <br /> #The derived key is generated by the package component from the start key. The PBKDF2 algorithm based on HMAC-SHA-1 function (see [RFC2898]) is used for the key derivation. The random number generator initialized with the current time is used to generate 16-byte salt for each file. The salt is used together with the start key to derive a unique 128-bit key for each file. The default iteration count for the algorithm is 1024. <br /> #The files are encrypted. The random number generator is used to generate the 8-byte initialization vector for the algorithm. The derived key is used together with the initialization vector to encrypt the file using the Blowfish algorithm in cipher feedback (CFB) mode (see [blowfish]).<br /> Each file that is encrypted is compressed before being encrypted. To allow the contents of the package file to be verified, it is necessary that encrypted files are flagged as &#039;STORED&#039; rather than &#039;DEFLATED&#039;. As entries which are &#039;STORED&#039; must have their size equal to the compressed size, it is necessary to store the uncompressed size in the manifest. The compressed size is stored in both the local file header and central directory record of the Zip file.&lt;br&gt;In an encrypted document all the document files should be encrypted. Non-document files, that are allowed to stay nonencrypted are the files that are recognized as a part of the package format: “mimetype”, “META-INF/manifest.xml” and the signature streams in “META-INF”.&lt;br&gt;&lt;/blockquote&gt;<br /> <br /> == Comply to the updated ODF 1.2 Encryption Specification in OOo 3.2 ==<br /> <br /> OOo 3.2 needs to comply with the updated encryption specification above. This mainly means that all algorithms used in the different steps needs to be documented in the manifest.xml. It does not mean that OOo would implement other algorithms now. (issue #XXXXX)<br /> <br /> == Missing Encryption of manifest.xml ==<br /> <br /> To some people it looks surprising that the manifest.xml is not encrypted. <br /> <br /> Actually, the manifest.xml contains the information that any ODF application needs to open the document, including the encryption and hash algorithms which have been used to encrypt the document...<br /> <br /> == Protecting the not encrypted manifest.xml in an encrypted document ==<br /> <br /> Since the manifest.xml can&#039;t be encrypted, someone could make modifications to manifest.xml in encrypted documents. <br /> <br /> It needs to be discussed if there needs to be some protection against this. <br /> <br /> For example, we could generate some signature/hash for encrypted version of manifest.xml ( with the common document encryption key ), and store it in a separate stream in the META-INF folder.<br /> <br /> This could be some OOo-only solution, and OOo would only warn when the signature is missing in documents written with OOo, or it could become part of some future version of the ODF specification. <br /> <br /> This topic needs further discussions...<br /> <br /> == Public Key Document Encryption ==<br /> <br /> It would be a nice feature to allow public key encryption for encrypting documents. People could encrypt the documents with their own and/or with other people&#039;s public key certificates, so only the owners of the corresponding private keys would be able to open the document. No need to exchange or remember passwords. <br /> <br /> == Digital Rights Management ==<br /> <br /> OpenOffice.org could support DRM. The part &quot;user can/can&#039;t open a document&quot; makes sense, can be implemented reliable. Enhanced rights/restrictions like &quot;can copy/print/...&quot; can&#039;t be guaranteed, because they could be removed easily in an open source application. <br /> <br /> See also [http://www.slideshare.net/Malte.Timmermann/openofficeorgstaroffice-drm-omc-workshop-2006-presentation my slides] from Sun&#039;s [http://www.openmediacommons.org/ Open Media Commons] workshop. <br /> <br /> == Password length and password pattern ==<br /> <br /> The ancient minimal password length in the password dialog should be removed, but don&#039;t allow empty passwords. (issue #i103783) <br /> <br /> In future it&#039;s better to add some good explanations about strong passwords to password dialogs and online help.<br /> <br /> What about adding some configuration items, so companies can configure OOo to adhere to their password rules? <br /> <br /> Ooo-password-properties: MinPasswordLength (default=1 if not set), MinNumbercharacters, MinSpecialCharacters, ForbiddenCharacters. <br /> <br /> We would then also need some dialog which explains the password rule to the user.<br /> <br /> == Thumbnails in encrypted documents ==<br /> <br /> ODF documents can contain a thumbnail, to display a small picture of the first page in a file explorer. <br /> <br /> Currently, encrypted documents contain encrypted thumbnails, which is not good for anything.<br /> <br /> Encrypted documents shouldn&#039;t store thumbnails. (issue #i103930)&lt;br&gt;<br /> <br /> The reason for this is that encrypted documents mustn&#039;t contain any non encrypted streams (with some exceptions). And since the encrypted document contains a standard bitmap as a thumbnail it makes no sense to store it in the document anyway. The bitmap should be part of the system integration. <br /> <br /> [[Category:Security]]</div>

Mav https://wiki.openoffice.org/w/index.php?title=Security/Encryption&diff=137750 2009-08-19T11:09:48Z

<p>Mav: /* Protecting the not encrypted manifest.xml in an encrypted document */</p> <hr /> <div>== Encrypted documents shouldn&#039;t have any non encrypted content ==<br /> <br /> Currently it is possible to add any non encrypted content into encrypted documents, simply by putting new streams into the zip archive. <br /> <br /> This way, someone could for example add macro code into documents without the need to know the password. <br /> <br /> The possibility to add content to an encrypted document is quite bad, and it becomes worse with macros, because passwords increase the level of trust the user has to a document, when it was encrypted by a person he knows. <br /> <br /> OOo will detect the macros, and ask the user whether or not to execute them. The user might trust the author of the document, and because of the encryption normally nobody should have been able to manipulate it, so he will probably allow OOo to execute the macros. At least, it&#039;s not possible to bind the macros to some event, so it would get executed automatically. <br /> <br /> In general, an encrypted document shouldn&#039;t have any non encrypted content. Exceptions are some files in the META-INF folder: manifest.xml, which is needed to get the encryption information, and the digital signature files also might not be encrypted, depending on the signature implementation. <br /> <br /> OOo should show a warning when an encrypted document contains streams which should be encrypted, but aren&#039;t. Additionally, macros should be disabled for the document. (issue #XXXXX)<br /> <br /> == Improving the Encryption Implementation in OOo 3.2 ==<br /> <br /> For OOo 3.2, we plan to improve the document encryption, or better, the handling of documents which have issues like mentioned above (issue #XXXXX). <br /> <br /> When OOo opens an encrypted document, it will check via the manifest if all files are encrypted. All encrypted files in a ODF zip archive must use the same encryption key. It is also necessary to check the actual file content, and not the manifest alone. This could be done on access, or in a background process for all files. When detecting not encrypted files, OOo will show a warning to the user, and will not execute any unencrypted macros in encrypted documents. <br /> <br /> == Enhancing the Encryption Specification for ODF 1.2 ==<br /> <br /> Currently the ODF specification specifies one way for encrypting ODF documents, and ODF applications can&#039;t chose different algorithms. &lt;br&gt; <br /> <br /> Choosing other encryption algorithms can be important, to comply with encryption rules from a company or Government using ODF. <br /> <br /> The information about the used algorithms (for each step)&amp;nbsp;need to be documented in the manifest.xml.&lt;br&gt; <br /> <br /> This is the latest draft of the proposal that we will send to the OASIS OpenDocument TC:&lt;br&gt; <br /> &lt;blockquote&gt;2.3 Encryption: &lt;/blockquote&gt;&lt;blockquote&gt;The encryption process takes place in the following multiple stages:&lt;br&gt; <br /> #The start key is generated and is provided to the package component. <br /> #The derived key is generated by the component based on the start key. <br /> #The files are encrypted based on the derived key and the encryption algorithm.<br /> The implementation must support at least the described below default way for the mentioned steps. In addition it might support encryption, where algorithms different from the default are used for the steps. The information regarding used for each step algorithms has to be provided in the manifest.xml accordingly. &lt;/blockquote&gt;&lt;blockquote&gt;The default way is:&lt;br&gt; <br /> #The start key is generated. The byte sequence representing the password in UTF-8 is used to generate a 20-byte SHA1 digest (see [RFC3174]). The result star key is passed to the package component. <br /> #The derived key is generated by the package component from the start key. The PBKDF2 algorithm based on HMAC-SHA-1 function (see [RFC2898]) is used for the key derivation. The random number generator initialized with the current time is used to generate 16-byte salt for each file. The salt is used together with the start key to derive a unique 128-bit key for each file. The default iteration count for the algorithm is 1024. <br /> #The files are encrypted. The random number generator is used to generate the 8-byte initialization vector for the algorithm. The derived key is used together with the initialization vector to encrypt the file using the Blowfish algorithm in cipher feedback (CFB) mode (see [blowfish]).<br /> Each file that is encrypted is compressed before being encrypted. To allow the contents of the package file to be verified, it is necessary that encrypted files are flagged as &#039;STORED&#039; rather than &#039;DEFLATED&#039;. As entries which are &#039;STORED&#039; must have their size equal to the compressed size, it is necessary to store the uncompressed size in the manifest. The compressed size is stored in both the local file header and central directory record of the Zip file.&lt;br&gt;In an encrypted document all the document files should be encrypted. Non-document files, that are allowed to stay nonencrypted are the files that are recognized as a part of the package format: “mimetype”, “META-INF/manifest.xml” and the signature streams in “META-INF”.&lt;br&gt;&lt;/blockquote&gt;<br /> <br /> == Comply to the updated ODF 1.2 Encryption Specification in OOo 3.2 ==<br /> <br /> OOo 3.2 needs to comply with the updated encryption specification above. This mainly means that all algorithms used in the different steps needs to be documented in the manifest.xml. It does not mean that OOo would implement other algorithms now. (issue #XXXXX)<br /> <br /> == Missing Encryption of manifest.xml ==<br /> <br /> To some people it looks surprising that the manifest.xml is not encrypted. <br /> <br /> Actually, the manifest.xml contains the information that any ODF application needs to open the document, including the encryption and hash algorithms which have been used to encrypt the document...<br /> <br /> == Protecting the not encrypted manifest.xml in an encrypted document ==<br /> <br /> Since the manifest.xml can&#039;t be encrypted, someone could make modifications to manifest.xml in encrypted documents. <br /> <br /> It needs to be discussed if there needs to be some protection against this. <br /> <br /> For example, we could generate some signature/hash for encrypted version of manifest.xml, and store it in a separate stream in the META-INF folder.<br /> <br /> This could be some OOo-only solution, and OOo would only warn when the signature is missing in documents written with OOo, or it could become part of some future version of the ODF specification. <br /> <br /> This topic needs further discussions...<br /> <br /> == Public Key Document Encryption ==<br /> <br /> It would be a nice feature to allow public key encryption for encrypting documents. People could encrypt the documents with their own and/or with other people&#039;s public key certificates, so only the owners of the corresponding private keys would be able to open the document. No need to exchange or remember passwords. <br /> <br /> == Digital Rights Management ==<br /> <br /> OpenOffice.org could support DRM. The part &quot;user can/can&#039;t open a document&quot; makes sense, can be implemented reliable. Enhanced rights/restrictions like &quot;can copy/print/...&quot; can&#039;t be guaranteed, because they could be removed easily in an open source application. <br /> <br /> See also [http://www.slideshare.net/Malte.Timmermann/openofficeorgstaroffice-drm-omc-workshop-2006-presentation my slides] from Sun&#039;s [http://www.openmediacommons.org/ Open Media Commons] workshop. <br /> <br /> == Password length and password pattern ==<br /> <br /> The ancient minimal password length in the password dialog should be removed, but don&#039;t allow empty passwords. (issue #i103783) <br /> <br /> In future it&#039;s better to add some good explanations about strong passwords to password dialogs and online help.<br /> <br /> What about adding some configuration items, so companies can configure OOo to adhere to their password rules? <br /> <br /> Ooo-password-properties: MinPasswordLength (default=1 if not set), MinNumbercharacters, MinSpecialCharacters, ForbiddenCharacters. <br /> <br /> We would then also need some dialog which explains the password rule to the user.<br /> <br /> == Thumbnails in encrypted documents ==<br /> <br /> ODF documents can contain a thumbnail, to display a small picture of the first page in a file explorer. <br /> <br /> Currently, encrypted documents contain encrypted thumbnails, which is not good for anything.<br /> <br /> Encrypted documents shouldn&#039;t store thumbnails. (issue #i103930)&lt;br&gt;<br /> <br /> The reason for this is that encrypted documents mustn&#039;t contain any non encrypted streams (with some exceptions). And since the encrypted document contains a standard bitmap as a thumbnail it makes no sense to store it in the document anyway. The bitmap should be part of the system integration. <br /> <br /> [[Category:Security]]</div>

Mav https://wiki.openoffice.org/w/index.php?title=Security/Encryption&diff=137749 2009-08-19T11:07:47Z

<p>Mav: /* Password length and password pattern */</p> <hr /> <div>== Encrypted documents shouldn&#039;t have any non encrypted content ==<br /> <br /> Currently it is possible to add any non encrypted content into encrypted documents, simply by putting new streams into the zip archive. <br /> <br /> This way, someone could for example add macro code into documents without the need to know the password. <br /> <br /> The possibility to add content to an encrypted document is quite bad, and it becomes worse with macros, because passwords increase the level of trust the user has to a document, when it was encrypted by a person he knows. <br /> <br /> OOo will detect the macros, and ask the user whether or not to execute them. The user might trust the author of the document, and because of the encryption normally nobody should have been able to manipulate it, so he will probably allow OOo to execute the macros. At least, it&#039;s not possible to bind the macros to some event, so it would get executed automatically. <br /> <br /> In general, an encrypted document shouldn&#039;t have any non encrypted content. Exceptions are some files in the META-INF folder: manifest.xml, which is needed to get the encryption information, and the digital signature files also might not be encrypted, depending on the signature implementation. <br /> <br /> OOo should show a warning when an encrypted document contains streams which should be encrypted, but aren&#039;t. Additionally, macros should be disabled for the document. (issue #XXXXX)<br /> <br /> == Improving the Encryption Implementation in OOo 3.2 ==<br /> <br /> For OOo 3.2, we plan to improve the document encryption, or better, the handling of documents which have issues like mentioned above (issue #XXXXX). <br /> <br /> When OOo opens an encrypted document, it will check via the manifest if all files are encrypted. All encrypted files in a ODF zip archive must use the same encryption key. It is also necessary to check the actual file content, and not the manifest alone. This could be done on access, or in a background process for all files. When detecting not encrypted files, OOo will show a warning to the user, and will not execute any unencrypted macros in encrypted documents. <br /> <br /> == Enhancing the Encryption Specification for ODF 1.2 ==<br /> <br /> Currently the ODF specification specifies one way for encrypting ODF documents, and ODF applications can&#039;t chose different algorithms. &lt;br&gt; <br /> <br /> Choosing other encryption algorithms can be important, to comply with encryption rules from a company or Government using ODF. <br /> <br /> The information about the used algorithms (for each step)&amp;nbsp;need to be documented in the manifest.xml.&lt;br&gt; <br /> <br /> This is the latest draft of the proposal that we will send to the OASIS OpenDocument TC:&lt;br&gt; <br /> &lt;blockquote&gt;2.3 Encryption: &lt;/blockquote&gt;&lt;blockquote&gt;The encryption process takes place in the following multiple stages:&lt;br&gt; <br /> #The start key is generated and is provided to the package component. <br /> #The derived key is generated by the component based on the start key. <br /> #The files are encrypted based on the derived key and the encryption algorithm.<br /> The implementation must support at least the described below default way for the mentioned steps. In addition it might support encryption, where algorithms different from the default are used for the steps. The information regarding used for each step algorithms has to be provided in the manifest.xml accordingly. &lt;/blockquote&gt;&lt;blockquote&gt;The default way is:&lt;br&gt; <br /> #The start key is generated. The byte sequence representing the password in UTF-8 is used to generate a 20-byte SHA1 digest (see [RFC3174]). The result star key is passed to the package component. <br /> #The derived key is generated by the package component from the start key. The PBKDF2 algorithm based on HMAC-SHA-1 function (see [RFC2898]) is used for the key derivation. The random number generator initialized with the current time is used to generate 16-byte salt for each file. The salt is used together with the start key to derive a unique 128-bit key for each file. The default iteration count for the algorithm is 1024. <br /> #The files are encrypted. The random number generator is used to generate the 8-byte initialization vector for the algorithm. The derived key is used together with the initialization vector to encrypt the file using the Blowfish algorithm in cipher feedback (CFB) mode (see [blowfish]).<br /> Each file that is encrypted is compressed before being encrypted. To allow the contents of the package file to be verified, it is necessary that encrypted files are flagged as &#039;STORED&#039; rather than &#039;DEFLATED&#039;. As entries which are &#039;STORED&#039; must have their size equal to the compressed size, it is necessary to store the uncompressed size in the manifest. The compressed size is stored in both the local file header and central directory record of the Zip file.&lt;br&gt;In an encrypted document all the document files should be encrypted. Non-document files, that are allowed to stay nonencrypted are the files that are recognized as a part of the package format: “mimetype”, “META-INF/manifest.xml” and the signature streams in “META-INF”.&lt;br&gt;&lt;/blockquote&gt;<br /> <br /> == Comply to the updated ODF 1.2 Encryption Specification in OOo 3.2 ==<br /> <br /> OOo 3.2 needs to comply with the updated encryption specification above. This mainly means that all algorithms used in the different steps needs to be documented in the manifest.xml. It does not mean that OOo would implement other algorithms now. (issue #XXXXX)<br /> <br /> == Missing Encryption of manifest.xml ==<br /> <br /> To some people it looks surprising that the manifest.xml is not encrypted. <br /> <br /> Actually, the manifest.xml contains the information that any ODF application needs to open the document, including the encryption and hash algorithms which have been used to encrypt the document...<br /> <br /> == Protecting the not encrypted manifest.xml in an encrypted document ==<br /> <br /> Since the manifest.xml can&#039;t be encrypted, someone could make modifications to manifest.xml in encrypted documents. <br /> <br /> It needs to be discussed if there needs to be some protection against this. <br /> <br /> For example, we could generate some signature/hash for manifest.xml, store it in a separate stream in the META-INF folder, encrypted with the same key like the other files in the package. <br /> <br /> This could be some OOo-only solution, and OOo would only warn when the signature is missing in documents written with OOo, or it could become part of some future version of the ODF specification. <br /> <br /> This topic needs further discussions...<br /> <br /> == Public Key Document Encryption ==<br /> <br /> It would be a nice feature to allow public key encryption for encrypting documents. People could encrypt the documents with their own and/or with other people&#039;s public key certificates, so only the owners of the corresponding private keys would be able to open the document. No need to exchange or remember passwords. <br /> <br /> == Digital Rights Management ==<br /> <br /> OpenOffice.org could support DRM. The part &quot;user can/can&#039;t open a document&quot; makes sense, can be implemented reliable. Enhanced rights/restrictions like &quot;can copy/print/...&quot; can&#039;t be guaranteed, because they could be removed easily in an open source application. <br /> <br /> See also [http://www.slideshare.net/Malte.Timmermann/openofficeorgstaroffice-drm-omc-workshop-2006-presentation my slides] from Sun&#039;s [http://www.openmediacommons.org/ Open Media Commons] workshop. <br /> <br /> == Password length and password pattern ==<br /> <br /> The ancient minimal password length in the password dialog should be removed, but don&#039;t allow empty passwords. (issue #i103783) <br /> <br /> In future it&#039;s better to add some good explanations about strong passwords to password dialogs and online help.<br /> <br /> What about adding some configuration items, so companies can configure OOo to adhere to their password rules? <br /> <br /> Ooo-password-properties: MinPasswordLength (default=1 if not set), MinNumbercharacters, MinSpecialCharacters, ForbiddenCharacters. <br /> <br /> We would then also need some dialog which explains the password rule to the user.<br /> <br /> == Thumbnails in encrypted documents ==<br /> <br /> ODF documents can contain a thumbnail, to display a small picture of the first page in a file explorer. <br /> <br /> Currently, encrypted documents contain encrypted thumbnails, which is not good for anything.<br /> <br /> Encrypted documents shouldn&#039;t store thumbnails. (issue #i103930)&lt;br&gt;<br /> <br /> The reason for this is that encrypted documents mustn&#039;t contain any non encrypted streams (with some exceptions). And since the encrypted document contains a standard bitmap as a thumbnail it makes no sense to store it in the document anyway. The bitmap should be part of the system integration. <br /> <br /> [[Category:Security]]</div>

Mav https://wiki.openoffice.org/w/index.php?title=Security/Encryption&diff=137748 2009-08-19T11:04:32Z

<p>Mav: /* Thumbnails in encrypted documents */</p> <hr /> <div>== Encrypted documents shouldn&#039;t have any non encrypted content ==<br /> <br /> Currently it is possible to add any non encrypted content into encrypted documents, simply by putting new streams into the zip archive. <br /> <br /> This way, someone could for example add macro code into documents without the need to know the password. <br /> <br /> The possibility to add content to an encrypted document is quite bad, and it becomes worse with macros, because passwords increase the level of trust the user has to a document, when it was encrypted by a person he knows. <br /> <br /> OOo will detect the macros, and ask the user whether or not to execute them. The user might trust the author of the document, and because of the encryption normally nobody should have been able to manipulate it, so he will probably allow OOo to execute the macros. At least, it&#039;s not possible to bind the macros to some event, so it would get executed automatically. <br /> <br /> In general, an encrypted document shouldn&#039;t have any non encrypted content. Exceptions are some files in the META-INF folder: manifest.xml, which is needed to get the encryption information, and the digital signature files also might not be encrypted, depending on the signature implementation. <br /> <br /> OOo should show a warning when an encrypted document contains streams which should be encrypted, but aren&#039;t. Additionally, macros should be disabled for the document. (issue #XXXXX)<br /> <br /> == Improving the Encryption Implementation in OOo 3.2 ==<br /> <br /> For OOo 3.2, we plan to improve the document encryption, or better, the handling of documents which have issues like mentioned above (issue #XXXXX). <br /> <br /> When OOo opens an encrypted document, it will check via the manifest if all files are encrypted. All encrypted files in a ODF zip archive must use the same encryption key. It is also necessary to check the actual file content, and not the manifest alone. This could be done on access, or in a background process for all files. When detecting not encrypted files, OOo will show a warning to the user, and will not execute any unencrypted macros in encrypted documents. <br /> <br /> == Enhancing the Encryption Specification for ODF 1.2 ==<br /> <br /> Currently the ODF specification specifies one way for encrypting ODF documents, and ODF applications can&#039;t chose different algorithms. &lt;br&gt; <br /> <br /> Choosing other encryption algorithms can be important, to comply with encryption rules from a company or Government using ODF. <br /> <br /> The information about the used algorithms (for each step)&amp;nbsp;need to be documented in the manifest.xml.&lt;br&gt; <br /> <br /> This is the latest draft of the proposal that we will send to the OASIS OpenDocument TC:&lt;br&gt; <br /> &lt;blockquote&gt;2.3 Encryption: &lt;/blockquote&gt;&lt;blockquote&gt;The encryption process takes place in the following multiple stages:&lt;br&gt; <br /> #The start key is generated and is provided to the package component. <br /> #The derived key is generated by the component based on the start key. <br /> #The files are encrypted based on the derived key and the encryption algorithm.<br /> The implementation must support at least the described below default way for the mentioned steps. In addition it might support encryption, where algorithms different from the default are used for the steps. The information regarding used for each step algorithms has to be provided in the manifest.xml accordingly. &lt;/blockquote&gt;&lt;blockquote&gt;The default way is:&lt;br&gt; <br /> #The start key is generated. The byte sequence representing the password in UTF-8 is used to generate a 20-byte SHA1 digest (see [RFC3174]). The result star key is passed to the package component. <br /> #The derived key is generated by the package component from the start key. The PBKDF2 algorithm based on HMAC-SHA-1 function (see [RFC2898]) is used for the key derivation. The random number generator initialized with the current time is used to generate 16-byte salt for each file. The salt is used together with the start key to derive a unique 128-bit key for each file. The default iteration count for the algorithm is 1024. <br /> #The files are encrypted. The random number generator is used to generate the 8-byte initialization vector for the algorithm. The derived key is used together with the initialization vector to encrypt the file using the Blowfish algorithm in cipher feedback (CFB) mode (see [blowfish]).<br /> Each file that is encrypted is compressed before being encrypted. To allow the contents of the package file to be verified, it is necessary that encrypted files are flagged as &#039;STORED&#039; rather than &#039;DEFLATED&#039;. As entries which are &#039;STORED&#039; must have their size equal to the compressed size, it is necessary to store the uncompressed size in the manifest. The compressed size is stored in both the local file header and central directory record of the Zip file.&lt;br&gt;In an encrypted document all the document files should be encrypted. Non-document files, that are allowed to stay nonencrypted are the files that are recognized as a part of the package format: “mimetype”, “META-INF/manifest.xml” and the signature streams in “META-INF”.&lt;br&gt;&lt;/blockquote&gt;<br /> <br /> == Comply to the updated ODF 1.2 Encryption Specification in OOo 3.2 ==<br /> <br /> OOo 3.2 needs to comply with the updated encryption specification above. This mainly means that all algorithms used in the different steps needs to be documented in the manifest.xml. It does not mean that OOo would implement other algorithms now. (issue #XXXXX)<br /> <br /> == Missing Encryption of manifest.xml ==<br /> <br /> To some people it looks surprising that the manifest.xml is not encrypted. <br /> <br /> Actually, the manifest.xml contains the information that any ODF application needs to open the document, including the encryption and hash algorithms which have been used to encrypt the document...<br /> <br /> == Protecting the not encrypted manifest.xml in an encrypted document ==<br /> <br /> Since the manifest.xml can&#039;t be encrypted, someone could make modifications to manifest.xml in encrypted documents. <br /> <br /> It needs to be discussed if there needs to be some protection against this. <br /> <br /> For example, we could generate some signature/hash for manifest.xml, store it in a separate stream in the META-INF folder, encrypted with the same key like the other files in the package. <br /> <br /> This could be some OOo-only solution, and OOo would only warn when the signature is missing in documents written with OOo, or it could become part of some future version of the ODF specification. <br /> <br /> This topic needs further discussions...<br /> <br /> == Public Key Document Encryption ==<br /> <br /> It would be a nice feature to allow public key encryption for encrypting documents. People could encrypt the documents with their own and/or with other people&#039;s public key certificates, so only the owners of the corresponding private keys would be able to open the document. No need to exchange or remember passwords. <br /> <br /> == Digital Rights Management ==<br /> <br /> OpenOffice.org could support DRM. The part &quot;user can/can&#039;t open a document&quot; makes sense, can be implemented reliable. Enhanced rights/restrictions like &quot;can copy/print/...&quot; can&#039;t be guaranteed, because they could be removed easily in an open source application. <br /> <br /> See also [http://www.slideshare.net/Malte.Timmermann/openofficeorgstaroffice-drm-omc-workshop-2006-presentation my slides] from Sun&#039;s [http://www.openmediacommons.org/ Open Media Commons] workshop. <br /> <br /> == Password length and password pattern ==<br /> <br /> Maybe we should remove the ancient minimal password length in the password dialog (but don&#039;t allow empty passwords). <br /> <br /> It&#039;s better to add some good explanations about strong passwords to password dialogs and online help. (Make sure that old OOo versions don&#039;t check the old min password length when loading encrypted documents) <br /> <br /> What about adding some configuration items, so companies can configure OOo to adhere to their password rules? <br /> <br /> Ooo-password-properties: MinPasswordLength (default=1 if not set), MinNumbercharacters, MinSpecialCharacters, ForbiddenCharacters. <br /> <br /> We would then also need some dialog which explains the password rule to the user. <br /> <br /> == Thumbnails in encrypted documents ==<br /> <br /> ODF documents can contain a thumbnail, to display a small picture of the first page in a file explorer. <br /> <br /> Currently, encrypted documents contain encrypted thumbnails, which is not good for anything.<br /> <br /> Encrypted documents shouldn&#039;t store thumbnails. (issue #i103930)&lt;br&gt;<br /> <br /> The reason for this is that encrypted documents mustn&#039;t contain any non encrypted streams (with some exceptions). And since the encrypted document contains a standard bitmap as a thumbnail it makes no sense to store it in the document anyway. The bitmap should be part of the system integration. <br /> <br /> [[Category:Security]]</div>

Mav https://wiki.openoffice.org/w/index.php?title=MediaWiki_Extension/Project_Scope_Statement&diff=62756 2008-02-08T12:36:17Z

<p>Mav: /* Project Description */</p> <hr /> <div>== Status ==<br /> ;Current Status:<br /> :draft, not yet approved by sponsors<br /> <br /> ;Status History<br /> :2007-09-05: [MMP] set up document<br /> <br /> == Project Name ==<br /> [[MediaWiki Extension]] 1.0<br /> <br /> == Project Description ==<br /> ;Phase 1<br /> :Provide an extension to OpenOffice.org to create and publish MediaWiki pages with OpenOffice.org by making use of new OpenOffice.org extension framework features<br /> ;Phase 2<br /> :Provide an extension to OpenOffice.org to load, edit and republish MediaWiki pages with OpenOffice.org<br /> <br /> ;iTeam<br /> : Mathias Bauer /MBA (Lead), Mikhail /MAV (engineering), Uwe /UFI (documentatiom), Éric /ES (QA), ? (User Experience)<br /> <br /> ;Sponsors<br /> :Mathias Bauer /MBA, Lutz Hoeger /LHO<br /> <br /> == Scope Inclusions ==<br /> === Goals and Objectives ===<br /> &#039;&#039;What business and/or technical needs will be filled by this project?&#039;&#039;<br /> * Enable wiki editing for OOo3 users<br /> <br /> == Requirements ==<br /> &#039;&#039;What end-user requirements will be addressed by this projects?&#039;&#039;<br /> <br /> === Functional requirements ===<br /> ;Phase 1<br /> * support of MediaWiki systems<br /> * create content with OOo and publish it to the wiki system <br /> <br /> ;Phase 2<br /> * visual roundtrip from wiki to OOo to wiki, ie. preserve document content and structure, headings, text styles (bold. italics), hyperlinks, lists, tables, images<br /> * functional roundtrip from wiki to OOo to wiki, ie. table of content macros, categories<br /> * template support for import from wiki<br /> * ...<br /> <br /> === Non-functional requirements ===<br /> * The interaction design will reflect the new integrated command locations<br /> * MediaWiki administration (URL, user, password) will happen in Tools-Option<br /> * Help is integrated<br /> <br /> == Deliverables ==<br /> &#039;&#039;What deliverables will be produced by this project?&#039;&#039;<br /> ;Phase 1<br /> * MediaWiki.oxt by December 2007 latest<br /> <br /> ;Phase 2<br /> * &#039;&#039;depends on progress of Phase 1&#039;&#039;<br /> <br /> == Scope Exclusions ==<br /> === Goals and Objectives ===<br /> &#039;&#039;What business and/or technical needs will be excluded from this project?&#039;&#039;<br /> * The project is divided into 2 segments. Phase 1 will offer the feature set to maintain the connection to the MediaWiki systems (Tools-Options), and the Send-To-MediaWiki functionality. Phase 1 does not include opening/reading of existing MediaWiki articles or parts thereof. This is planned for Phase 2.<br /> <br /> === Requirements ===<br /> &#039;&#039;What end-user requirements will be excluded from this project?&#039;&#039;<br /> * Support of other wiki systems than MediaWiki<br /> * WikiText code roundtrip of MediaWiki content<br /> * embedded HTML on wiki pages will be replaced by WikiText<br /> * Images can not be uploaded to the wiki systems<br /> * ...<br /> <br /> == Deliverables ==<br /> &#039;&#039;What deliverables will be excluded from this project?&#039;&#039;<br /> * direct customer support<br /> * publishing the extension on the extension repository<br /> * marketing for the extension<br /> <br /> [[Category:MediaWiki Extension|P]]</div>

Mav https://wiki.openoffice.org/w/index.php?title=MediaWiki_Extension/Action_Items&diff=62751 2008-02-08T10:42:48Z

<p>Mav: </p> <hr /> <div>== Mathias ==<br /> <br /> == Éric ==<br /> # Test the fixed version of the RC<br /> <br /> == Mikhail ==<br /> # Fix the known issues in RC and provide it for testing<br /> <br /> == Anyone ==<br /> # What are common/typical extensions for MediaWiki installations?<br /> # We need a positive list of MediaWiki tags that we support and a negative list of tags that we do not support.<br /> <br /> [[Category:MediaWiki Extension|A]]<br /> [[Category:To-Do]]</div>

Mav https://wiki.openoffice.org/w/index.php?title=MediaWiki_Extension/Release_Map&diff=62750 2008-02-08T10:40:18Z

<p>Mav: </p> <hr /> <div>== QA Approved ==<br /> ; Release Date<br /> : February 2008<br /> <br /> == Release Candidate 1 ==<br /> ; Release Date<br /> : December 2007<br /> ; Features<br /> : complete<br /> <br /> == Product Backlog ==<br /> * localization<br /> * integrated help<br /> * ...<br /> <br /> == Alpha 4 ==<br /> ; Release Date<br /> : TBD<br /> ; Features<br /> : MediaWiki Options move to Internet node.<br /> : ...<br /> <br /> == Alpha 3 ==<br /> ; Release Date<br /> : 13 December 2007<br /> ; Features<br /> : Writer support (add To MediaWiki... command to Writer-File-Send)<br /> : Passwords are saved.<br /> : string review by MMP<br /> <br /> == Alpha 2 ==<br /> ; Release Date<br /> : 26 November 2007<br /> ; Features<br /> : inline progress indicator for Send dialog (according to spec)<br /> : HTTPS support (show alert if unknown certificate needs to be accepted)<br /> : Options panel (temporary under Tools-Writer-MediaWiki)<br /> <br /> == Alpha 1 ==<br /> ; Release Date<br /> : October 2007<br /> ; Features<br /> : This release will focus on export of Writer/web documents directly to a MediaWiki.<br /> : File-Send submenu gets a new command to send documents to the Wiki<br /> : OOo 2.3&#039;s XSLT Transformation is used<br /> : Alpha 1 is English only<br /> : Alpha 1 is HTTP only<br /> : Alpha 1 is Writer/Web only<br /> : Alpha 1 does not have final Send, Login dialog<br /> : Alpha 1 has no progress indicator yet.<br /> <br /> <br /> <br /> [[Category:MediaWiki Extension|R]]</div>

Mav https://wiki.openoffice.org/w/index.php?title=MediaWiki_Extension/Action_Items&diff=61524 2008-01-24T15:13:32Z

<p>Mav: </p> <hr /> <div>== Mathias ==<br /> # provide Options dialog for Alpha 2<br /> # talk to MBA about Howie&#039;s participation<br /> # talk to Thomas Mitzka on more [[MediaWiki Extension/Use Cases]] (met with Thomas, notes TBD)<br /> # Open Dialog<br /> # Error Strings<br /> # collect input from/with marketing to &#039;&#039;launch&#039;&#039; Alpha x in the extension repository.<br /> # Create OOo template &#039;&#039;MediaWiki.ott&#039;&#039; or? &#039;&#039;MediaWiki.oth&#039;&#039; that looks a bit like a MediWiki page /wrt styles, see [[MediaWiki Extension/Meetings#6-Sep-2007]]<br /> ; done<br /> # propagate new inline progress control<br /> <br /> == Éric ==<br /> # Migrate wiki test server to so-penelope<br /> # set up an https server.<br /> <br /> == Mikhail ==<br /> # add HelpIDs to the UI<br /> <br /> == Anyone ==<br /> # Find typical [[MediaWiki Extension/Use Cases|Use Cases]] for MediaWiki<br /> ## Wikipedia<br /> ## oo-wiki<br /> ## Ubuntu-wiki<br /> # What are common/typical extensions for MediaWiki installations?<br /> # We need a positive list of MediaWiki tags that we support and a negative list of tags that we do not support.<br /> <br /> [[Category:MediaWiki Extension|A]]<br /> [[Category:To-Do]]</div>

Mav https://wiki.openoffice.org/w/index.php?title=MediaWiki_Extension/Action_Items&diff=54003 2007-11-15T16:24:59Z

<p>Mav: /* Mikhail */</p> <hr /> <div>== Matthias ==<br /> # talk to MBA about Howie&#039;s participation<br /> # talk to Thomas Mitzka on more [[MediaWiki Extension/Use Cases]]<br /> # provide spec for Alpha 1<br /> ## Add Dialog<br /> ## Settings Dialog<br /> ## Error Strings<br /> # collect input from/with marketing to &#039;&#039;launch&#039;&#039; Alpha 1 in the extension repository.<br /> # propagate new inline progress control <br /> # Create OOo template &#039;&#039;MediaWiki.ott&#039;&#039; or? &#039;&#039;MediaWiki.oth&#039;&#039; that looks a bit like a MediWiki page /wrt styles, see [[MediaWiki Extension/Meetings#6-Sep-2007]]<br /> <br /> == Éric ==<br /> # add query with MediaWiki Tasks to our [[MediaWiki Extension]] home page<br /> # &lt;strike&gt;Clarify if the MediaWiki filter is installed and enabled for OOo 2.3 -- according to the [http://specs.openoffice.org/writer/fileIO/MediaWiki_Export_Filter.odt spec] it should be preinstalled.&lt;/strike&gt;<br /> <br /> -&gt; Yes, it should but is currently not: issue [http://www.openoffice.org/issues/show_bug.cgi?id=82028 82028]<br /> <br /> == Mikhail ==<br /> # check sources with LGPL licenses into CWS<br /> # develop [[MediaWiki_Extension/Release_Map|Alpha 2]]<br /> # add HelpIDs to the UI<br /> <br /> == Anyone ==<br /> # Find typical [[MediaWiki Extension/Use Cases|Use Cases]] for MediaWiki<br /> ## Wikipedia<br /> ## oo-wiki<br /> ## Ubuntu-wiki<br /> # What are common/typical extensions for MediaWiki installations?<br /> # We need a positive list of MediaWiki tags that we support and a negative list of tags that we do not support.<br /> <br /> [[Category:MediaWiki Extension|A]]<br /> [[Category:To-Do]]</div>

Mav https://wiki.openoffice.org/w/index.php?title=MediaWiki_Extension/Action_Items&diff=54002 2007-11-15T16:24:29Z

<p>Mav: /* Mikhail */</p> <hr /> <div>== Matthias ==<br /> # talk to MBA about Howie&#039;s participation<br /> # talk to Thomas Mitzka on more [[MediaWiki Extension/Use Cases]]<br /> # provide spec for Alpha 1<br /> ## Add Dialog<br /> ## Settings Dialog<br /> ## Error Strings<br /> # collect input from/with marketing to &#039;&#039;launch&#039;&#039; Alpha 1 in the extension repository.<br /> # propagate new inline progress control <br /> # Create OOo template &#039;&#039;MediaWiki.ott&#039;&#039; or? &#039;&#039;MediaWiki.oth&#039;&#039; that looks a bit like a MediWiki page /wrt styles, see [[MediaWiki Extension/Meetings#6-Sep-2007]]<br /> <br /> == Éric ==<br /> # add query with MediaWiki Tasks to our [[MediaWiki Extension]] home page<br /> # &lt;strike&gt;Clarify if the MediaWiki filter is installed and enabled for OOo 2.3 -- according to the [http://specs.openoffice.org/writer/fileIO/MediaWiki_Export_Filter.odt spec] it should be preinstalled.&lt;/strike&gt;<br /> <br /> -&gt; Yes, it should but is currently not: issue [http://www.openoffice.org/issues/show_bug.cgi?id=82028 82028]<br /> <br /> == Mikhail ==<br /> # check sources with LGPL licenses into CWS<br /> # develop [[MediaWiki_Extension/Release_Map|Alpha 2]], focus on File-Send menu and Export functionality<br /> # add HelpIDs to the UI<br /> <br /> == Anyone ==<br /> # Find typical [[MediaWiki Extension/Use Cases|Use Cases]] for MediaWiki<br /> ## Wikipedia<br /> ## oo-wiki<br /> ## Ubuntu-wiki<br /> # What are common/typical extensions for MediaWiki installations?<br /> # We need a positive list of MediaWiki tags that we support and a negative list of tags that we do not support.<br /> <br /> [[Category:MediaWiki Extension|A]]<br /> [[Category:To-Do]]</div>

Mav https://wiki.openoffice.org/w/index.php?title=Developers_FAQ&diff=39343 2007-07-16T14:23:41Z

<p>Mav: </p> <hr /> <div>The Developers FAQ is a collection from different questions asked by Developers who are new to OpenOffice.org:<br /> <br /> This is work in progress, the developer mentioned behind the question will write the answer soon.<br /> <br /> <br /> ==Framework==<br /> * Description of the SFX2 framework? (MBA)<br /> * There are the roles of the different shells and views? See [[Framework/Article/Implementation_of_the_Dispatch_API_In_SFX2|Implementation of the Dispatch API In SFX2]]<br /> * Explanation of the dispatch/interceptor mechanism / command handling? See [[Framework/Article/Implementation_of_the_Dispatch_API_In_SFX2|Implementation of the Dispatch API In SFX2]]<br /> * How is the slot mechanism implemented, and how is the listener and broadcast mechanism implemented? See [[Framework/Article/Implementation_of_the_Dispatch_API_In_SFX2|Implementation of the Dispatch API In SFX2]]<br /> * Generic user interface: How does the framework implement the interface management, how to load toolbar, and how to implement berth area? See [[Framework/Article/General_Architecture_Of_The_Framework_User_Interface_Implementation|General Architecture of the Framework User Interface]]<br /> * Filter configuration<br /> ** [http://api.openoffice.org/docs/DevelopersGuide/OfficeDev/OfficeDev.xhtml#1_2_4_Integrating_Import_and_Export_Filters Developer&#039;s Guide 7.2.4 Integrating Import and Export Filters]<br /> ** Note: Description of the used configuration format in XML is outdated.<br /> * API for accessing OOo package format<br /> ** http://api.openoffice.org/docs/common/ref/com/sun/star/embed/Storage.html<br /> * Embedding<br /> ** http://wiki.services.openoffice.org/wiki/Framework/Article/General_Architecture_Of_Documents_Embedding<br /> * Templates<br /> ** http://api.openoffice.org/docs/common/ref/com/sun/star/frame/TemplateAccess.html<br /> ** <br /> * Add-ons / Extensions support<br /> ** [[Framework/WorkInProgress/Addon_Menu_Toolbar_Merging|Support merging into the Office menu bar/toolbars.]]<br /> ** [[Framework/Article/Generic_UNO_Interfaces_for_complex_toolbar_controls|Complex toolbar controls for add-ons.]]<br /> ** [http://api.openoffice.org/docs/DevelopersGuide/Components/Components.xhtml#1_7_3_Add-Ons Developer&#039;s Guide 4.7.3 Add-ons]<br /> ** Add-on examples with sources (http://framework.openoffice.org/servlets/ProjectDocumentList?folderID=226&amp;expandFolder=226&amp;folderID=72) <br /> * The general part of the document storing/loading process<br /> ** [http://api.openoffice.org/docs/DevelopersGuide/OfficeDev/OfficeDev.xhtml#1_1_5_1_Loading_Documents Documents loading]<br /> ** [http://api.openoffice.org/docs/DevelopersGuide/OfficeDev/OfficeDev.xhtml#1_1_5_3_Storing_Documents Documents storing]<br /> <br /> ==[http://udk.openoffice.org UDK]==<br /> * Mechanisms of Multi-Platform support ([[KR]]) <br /> :I assume this means multiple language support, please see [[Uno/Article/Working_with_Environments%2C_Mappings_%26_Objects|Working with Environments, Mappings &amp; Objects]] .<br /> * How to communicate with other OOo components, and how to implement a bridge ([[KR]]) <br /> : There is a tutorial for implementing C++ bridges, please see http://udk.openoffice.org/cpp/man/cpp_bridges.html . Most [[Uno/Binary|Binary Uno]] bridges are implemented in the [[Uno/Binary/Module/bridges|bridges]] module.<br /> * [[Uno/PyUno|Python Uno]] components may be run within the OOo process - how can they be called from [[Java]], [[C++]] or [[BASIC|StarBasic]]? ([[KR]])<br /> : [[Uno/PyUno|Python Uno]] components may be accessed like any other component, e.g. by doing a &quot;createInstance&quot; with a service which is implemented in [[Uno/PyUno|Python Uno]].<br /> * The relationship between [[Uno]], COM+, CORBA ([[KR]])<br /> : For a comparison between [[Uno]] and CORBA please see http://udk.openoffice.org/common/man/comparison_uno_corba.html , though [[Uno]] nowadays does support multiple inheritance. Also there was an effort, which unfortunately did not complete, do implement a [[Uno]] CORBA bridge, please see http://udk.openoffice.org/common/man/concept/uno_corba.html .<br /> : There is no document regarding [[Uno]] and (D)COM+. [[Uno]] has some similarities with COM+:<br /> :* &quot;queryInterface&quot;<br /> :* Language agnostic<br /> :* &quot;Apartments&quot;, please see the [[Uno/Spec/Threading-Model|Uno Threading-Model]] for details.<br /> :* Components<br /> :* Remote transparency<br /> <br /> ==Application, Writer==<br /> * Structure of tables? [[Writer_Core_And_Layout]]<br /> * Mechanism/Implementation of Undo? [[Writer_Core_And_Layout]]<br /> * Mechanism/Implementation of Frames, relationship? [[Writer_Core_And_Layout]]<br /> * Class structure of SwNode, SwNodes, SwNodeIndex, ..., relationship? [[Writer_Core_And_Layout]]<br /> * The relationship between the class ViewShell and SwDoc (OS)<br /> The ViewShell is created as indirect member of the SwPagePreview or as base class of SwWrtShell, SwFEShell, SwEditShell, SwCrsrShell as member of the SwView. This stack of shells provides access from SwView/SwPagePreview to the document. The ViewShell mostly for output (printing, painting) and the others for cursor travelling and content modification.<br /> <br /> ==Application, Draw/Impress==<br /> * The mechanism of slide show and animation (what is the difference between before and after)?<br /> ** The slideshow itself, and all animation functionality are implemented in the [[Slideshow]] module. (What is the meeaing of &quot;before&quot; and &quot;after&quot; in the context of this question?)<br /> * Copy&amp;Paste: Memory structure of clipboard in SD, difference between coping objects inside slides and coping objects from or into other applications like SW, SC? <br /> ** Clipboard between the same application type is done by using core implementations. Clipboard between different application types is done by using xml.<br /> * Mechanism of designing and implementation of master page and layout style in presentation (CL)<br /> ** Master pages and layout styles are already implemented in OOo.<br /> <br /> * Flash Export: (CL)<br /> ** Difference between the export of the simple character and the complex character?<br /> *** Simple characters are exported using the font tags of the flash format, complex characters are exported as polygons.<br /> ** The implementation of the Polygon in VCL. Such as the EM square，Body，Ascent and Descent to realize of the glyph?<br /> *** This question needs more data as the implementation of the Polygon in VCl itself has nothing to do with glyphs. It is only used to represend glyphs.<br /> ** The custom animation will be lost after the slides being exported into the swf. What cause it? There is no support to export the animation, is there? Do you have any plan to consummate it? And what&#039;s your purpose in this area?<br /> *** It is caused by the absence of an implementation that exports this particular feature. There is currently no assigned developer for the task to add this feature to the flash export. One developer from Redflag is activly contributing to the flash export.<br /> <br /> ==Application, Calc==<br /> * How are the areas for charts recognized, and how does the update notification work? (NN)<br /> ** Note that much of this has changed for the new chart. Don&#039;t make any changes based on older versions (before SRC680m213).<br /> ** The chart implementation uses the UNO API (XDataProvider) to get data sequence objects for each data series, and registers itself as modify listener with these objects.<br /> ** For the time when a chart object hasn&#039;t been loaded yet, Calc has its own internal listener (ScChartListener) to load the chart if its data is changed.<br /> * Relationship between cells, sheets and workbooks (class diagram) (NN)<br /> ** The core implementation of the document is class ScDocument. It has an array of pointers to ScTable (implementation of a sheet). Each sheet has a fixed-size array of ScColumn objects. Each ScColumn object holds the cells in one column.<br /> ** The cells are implemented by base class ScBaseCell and derived classes:<br /> *** ScNoteCell (empty except for note and listeners)<br /> *** ScValueCell (constant numeric value)<br /> *** ScStringCell (simple text)<br /> *** ScEditCell (formatted or multi-paragraph text)<br /> *** ScFormulaCell (formula)<br /> * Copy&amp;Paste: What&#039;s happening on Copy directly, and later if someone pastes into same spreadsheet or other application (NN)<br /> ** Implementation of copy for cells is at ScViewFunc::CopyToClip. The cells are copied into an internal object (ScDocument), then a ScTransferObj is created as the interface to the clipboard.<br /> ** Pasting into Calc copies the cells directly from the internal ScDocument object. Clipboard data in other formats for external applications is created on demand by ScTransferObj (ScTransferObj::GetData).<br /> <br /> ==Application, Database==<br /> * Why was the dbase driver engineered into file_based driver? And compared with the text/csv driver, what are the advantages of it in OOo&#039;s database, and how it was being designed in OOo&#039;s database?<br /> ** The &quot;file&quot; driver is not an own driver, it&#039;s a framework for, well, file-based databases, where a single file represents a table, and all such files in a given directory comprise the database. Both the text/csv driver and the dBase driver use this framework.<br /> ** The advantage of the dBase driver over the text/csv driver is that the former can read dBase files, while the latter can&#039;t.<br /> ** What do you mean with &quot;was being designed&quot;?<br /> * What are the project&#039;s short-term plan or the direction of development now?<br /> ** There are two areas which we currently mainly focus on: The new report designer which will be part of OpenOffice.org 2.3, and improved programmability of Base, where the first step is to allow embedding macros in database document.<br /> * In the project named &quot;Native, cross-platform access to MS Access databases&quot;, what is the current solution? Is there anyone beginning to re-engineer the MDB format himself?<br /> ** The current solution is employing [http://mdbtools.sourceforge.net/ MDB-Tools], a third-party product which allows access to .mdb files. The driver based on MDB-Tools is in [http://eis.services.openoffice.org/EIS2/cws.ShowCWS?logon=true&amp;Id=2959&amp;Path=SRC680%2Fmdbdriver02 alpha state], and still has serious shortcomings. The project itself is currently stalled, nobody is actively working on it. Also, nobody is working on doing a reverse-engineering of the MSA file format. If somebody wants to do this, we should seriously investigate whether it makes more sense to support and improve existing reverse engineering efforts, namely MDB-Tools.<br /> <br /> ==Application, Chart2==<br /> * Description of the Chart2 module: [http://graphics.openoffice.org/chart/chart2codestructure.html Code Structure of chart2]<br /> <br /> ==General Questions==<br /> * Which are the common threads started at start up time and used by all OOo applications at runtime, and what are their functions? ([[KR]])?<br /> : A first over regarding the threads can be found here: [[Effort/Implement_Basic_Threading-Architecture#Threads]] More to come ...<br /> * Structure of VCL? See [[Sort_of_documentation_about_VCL_around_Native_Mac_OS_X_port]]<br /> ** A general overview about VCL was created by Eric Bachard, please have a look [http://wiki.services.openoffice.org/wiki/User:Ericb#Sort_of_documentation_about_VCL_around_Native_Mac_OS_X_port here]<br /> * [[TextRenderingProcess|Text rendering process]]<br /> * Memory Management (MT/MHU)<br /> * How to improve stability, and where to start? Beside doing thorough QA, you might use tools like [http://tools.www.openoffice.org/debugging/usingvalgrind.sxw Valgrind] or [http://tools.openoffice.org/files/documents/15/872/BoundsChecker.html BoundsChecker]<br /> * How to improve performance, and where to start? Use a [http://en.wikipedia.org/wiki/Performance_analysis profiler] to analyze the runtime behavior of the code that you want to improve.<br /> * Which code of OOo is responsible for the VBA Macro parse? How are they implemented?<br /> ** This is done by a hard coded parser in basic/source/comp<br /> * How is the code implemented to fulfill the specification of Unicode and gb2312 (SB): Follow the source code links for &amp;ldquo;UTF7&amp;ldquo; and &amp;ldquo;UTF8&amp;ldquo; (Unicode) and &amp;ldquo;EUC_CN&amp;rdquo; (GB2312) in [http://porting.openoffice.org/source/browse/porting/sal/textenc/textenc.cxx?rev=1.6&amp;view=markup sal/textenc/textenc.cxx:1.6].<br /> * How/where is the Boost library used? See [[boost]] for an overview.<br /> * The process of SVG protraction and SVG parse. The relationship between controller protraction and the resource of the controller. (SJ)<br /> * Mozilla and ActiveX plugins (MAV)<br /> * Which internet protocols are supported in OOo, and what can be improved to the network ability of OOo? (KSO)<br /> <br /> ==Feature Questions==<br /> * Currently a document can only be processed by one of the OOo applications - what about having just one application processing all kind of documents?<br /> * Are there any plans to integrate a desktop search engine? (Could be done as an extension)<br /> * Any plans to introduce classes comparable to CObject and CWinApp in MFC? (???)<br /> <br /> <br /> [[Category:FAQ]]<br /> [[Category:Developer_Documentation]]</div>

Mav https://wiki.openoffice.org/w/index.php?title=Developers_FAQ&diff=39334 2007-07-16T13:00:44Z

<p>Mav: </p> <hr /> <div>The Developers FAQ is a collection from different questions asked by Developers who are new to OpenOffice.org:<br /> <br /> This is work in progress, the developer mentioned behind the question will write the answer soon.<br /> <br /> <br /> ==Framework==<br /> * Description of the SFX2 framework? (MBA)<br /> * There are the roles of the different shells and views? See [[Framework/Article/Implementation_of_the_Dispatch_API_In_SFX2|Implementation of the Dispatch API In SFX2]]<br /> * Explanation of the dispatch/interceptor mechanism / command handling? See [[Framework/Article/Implementation_of_the_Dispatch_API_In_SFX2|Implementation of the Dispatch API In SFX2]]<br /> * How is the slot mechanism implemented, and how is the listener and broadcast mechanism implemented? See [[Framework/Article/Implementation_of_the_Dispatch_API_In_SFX2|Implementation of the Dispatch API In SFX2]]<br /> * Generic user interface: How does the framework implement the interface management, how to load toolbar, and how to implement berth area? See [[Framework/Article/General_Architecture_Of_The_Framework_User_Interface_Implementation|General Architecture of the Framework User Interface]]<br /> * Filter configuration<br /> ** [http://api.openoffice.org/docs/DevelopersGuide/OfficeDev/OfficeDev.xhtml#1_2_4_Integrating_Import_and_Export_Filters Developer&#039;s Guide 7.2.4 Integrating Import and Export Filters]<br /> ** Note: Description of the used configuration format in XML is outdated.<br /> * API for accessing OOo package format<br /> ** http://api.openoffice.org/docs/common/ref/com/sun/star/embed/Storage.html<br /> * Embedding<br /> ** http://wiki.services.openoffice.org/wiki/Framework/Article/General_Architecture_Of_Documents_Embedding<br /> * Templates (MAV)<br /> * Add-ons / Extensions support<br /> ** [[Framework/WorkInProgress/Addon_Menu_Toolbar_Merging|Support merging into the Office menu bar/toolbars.]]<br /> ** [[Framework/Article/Generic_UNO_Interfaces_for_complex_toolbar_controls|Complex toolbar controls for add-ons.]]<br /> ** [http://api.openoffice.org/docs/DevelopersGuide/Components/Components.xhtml#1_7_3_Add-Ons Developer&#039;s Guide 4.7.3 Add-ons]<br /> ** Add-on examples with sources (http://framework.openoffice.org/servlets/ProjectDocumentList?folderID=226&amp;expandFolder=226&amp;folderID=72) <br /> * The general part of the document storing/loading process (MAV)<br /> ** [http://api.openoffice.org/docs/DevelopersGuide/OfficeDev/OfficeDev.xhtml#1_1_5_1_Loading_Documents Documents loading]<br /> ** [http://api.openoffice.org/docs/DevelopersGuide/OfficeDev/OfficeDev.xhtml#1_1_5_3_Storing_Documents Documents storing]<br /> <br /> ==[http://udk.openoffice.org UDK]==<br /> * Mechanisms of Multi-Platform support ([[KR]]) <br /> :I assume this means multiple language support, please see [[Uno/Article/Working_with_Environments%2C_Mappings_%26_Objects|Working with Environments, Mappings &amp; Objects]] .<br /> * How to communicate with other OOo components, and how to implement a bridge ([[KR]]) <br /> : There is a tutorial for implementing C++ bridges, please see http://udk.openoffice.org/cpp/man/cpp_bridges.html . Most [[Uno/Binary|Binary Uno]] bridges are implemented in the [[Uno/Binary/Module/bridges|bridges]] module.<br /> * [[Uno/PyUno|Python Uno]] components may be run within the OOo process - how can they be called from [[Java]], [[C++]] or [[BASIC|StarBasic]]? ([[KR]])<br /> : [[Uno/PyUno|Python Uno]] components may be accessed like any other component, e.g. by doing a &quot;createInstance&quot; with a service which is implemented in [[Uno/PyUno|Python Uno]].<br /> * The relationship between [[Uno]], COM+, CORBA ([[KR]])<br /> : For a comparison between [[Uno]] and CORBA please see http://udk.openoffice.org/common/man/comparison_uno_corba.html , though [[Uno]] nowadays does support multiple inheritance. Also there was an effort, which unfortunately did not complete, do implement a [[Uno]] CORBA bridge, please see http://udk.openoffice.org/common/man/concept/uno_corba.html .<br /> : There is no document regarding [[Uno]] and (D)COM+. [[Uno]] has some similarities with COM+:<br /> :* &quot;queryInterface&quot;<br /> :* Language agnostic<br /> :* &quot;Apartments&quot;, please see the [[Uno/Spec/Threading-Model|Uno Threading-Model]] for details.<br /> :* Components<br /> :* Remote transparency<br /> <br /> ==Application, Writer==<br /> * Structure of tables? [[Writer_Core_And_Layout]]<br /> * Mechanism/Implementation of Undo? [[Writer_Core_And_Layout]]<br /> * Mechanism/Implementation of Frames, relationship? [[Writer_Core_And_Layout]]<br /> * Class structure of SwNode, SwNodes, SwNodeIndex, ..., relationship? [[Writer_Core_And_Layout]]<br /> * The relationship between the class ViewShell and SwDoc (OS)<br /> The ViewShell is created as indirect member of the SwPagePreview or as base class of SwWrtShell, SwFEShell, SwEditShell, SwCrsrShell as member of the SwView. This stack of shells provides access from SwView/SwPagePreview to the document. The ViewShell mostly for output (printing, painting) and the others for cursor travelling and content modification.<br /> <br /> ==Application, Draw/Impress==<br /> * The mechanism of slide show and animation (what is the difference between before and after)?<br /> ** The slideshow itself, and all animation functionality are implemented in the [[Slideshow]] module. (What is the meeaing of &quot;before&quot; and &quot;after&quot; in the context of this question?)<br /> * Copy&amp;Paste: Memory structure of clipboard in SD, difference between coping objects inside slides and coping objects from or into other applications like SW, SC? <br /> ** Clipboard between the same application type is done by using core implementations. Clipboard between different application types is done by using xml.<br /> * Mechanism of designing and implementation of master page and layout style in presentation (CL)<br /> ** Master pages and layout styles are already implemented in OOo.<br /> <br /> * Flash Export: (CL)<br /> ** Difference between the export of the simple character and the complex character?<br /> *** Simple characters are exported using the font tags of the flash format, complex characters are exported as polygons.<br /> ** The implementation of the Polygon in VCL. Such as the EM square，Body，Ascent and Descent to realize of the glyph?<br /> *** This question needs more data as the implementation of the Polygon in VCl itself has nothing to do with glyphs. It is only used to represend glyphs.<br /> ** The custom animation will be lost after the slides being exported into the swf. What cause it? There is no support to export the animation, is there? Do you have any plan to consummate it? And what&#039;s your purpose in this area?<br /> *** It is caused by the absence of an implementation that exports this particular feature. There is currently no assigned developer for the task to add this feature to the flash export. One developer from Redflag is activly contributing to the flash export.<br /> <br /> ==Application, Calc==<br /> * How are the areas for charts recognized, and how does the update notification work? (NN)<br /> ** Note that much of this has changed for the new chart. Don&#039;t make any changes based on older versions (before SRC680m213).<br /> ** The chart implementation uses the UNO API (XDataProvider) to get data sequence objects for each data series, and registers itself as modify listener with these objects.<br /> ** For the time when a chart object hasn&#039;t been loaded yet, Calc has its own internal listener (ScChartListener) to load the chart if its data is changed.<br /> * Relationship between cells, sheets and workbooks (class diagram) (NN)<br /> ** The core implementation of the document is class ScDocument. It has an array of pointers to ScTable (implementation of a sheet). Each sheet has a fixed-size array of ScColumn objects. Each ScColumn object holds the cells in one column.<br /> ** The cells are implemented by base class ScBaseCell and derived classes:<br /> *** ScNoteCell (empty except for note and listeners)<br /> *** ScValueCell (constant numeric value)<br /> *** ScStringCell (simple text)<br /> *** ScEditCell (formatted or multi-paragraph text)<br /> *** ScFormulaCell (formula)<br /> * Copy&amp;Paste: What&#039;s happening on Copy directly, and later if someone pastes into same spreadsheet or other application (NN)<br /> ** Implementation of copy for cells is at ScViewFunc::CopyToClip. The cells are copied into an internal object (ScDocument), then a ScTransferObj is created as the interface to the clipboard.<br /> ** Pasting into Calc copies the cells directly from the internal ScDocument object. Clipboard data in other formats for external applications is created on demand by ScTransferObj (ScTransferObj::GetData).<br /> <br /> ==Application, Database==<br /> * Why was the dbase driver engineered into file_based driver? And compared with the text/csv driver, what are the advantages of it in OOo&#039;s database, and how it was being designed in OOo&#039;s database?<br /> ** The &quot;file&quot; driver is not an own driver, it&#039;s a framework for, well, file-based databases, where a single file represents a table, and all such files in a given directory comprise the database. Both the text/csv driver and the dBase driver use this framework.<br /> ** The advantage of the dBase driver over the text/csv driver is that the former can read dBase files, while the latter can&#039;t.<br /> ** What do you mean with &quot;was being designed&quot;?<br /> * What are the project&#039;s short-term plan or the direction of development now?<br /> ** There are two areas which we currently mainly focus on: The new report designer which will be part of OpenOffice.org 2.3, and improved programmability of Base, where the first step is to allow embedding macros in database document.<br /> * In the project named &quot;Native, cross-platform access to MS Access databases&quot;, what is the current solution? Is there anyone beginning to re-engineer the MDB format himself?<br /> ** The current solution is employing [http://mdbtools.sourceforge.net/ MDB-Tools], a third-party product which allows access to .mdb files. The driver based on MDB-Tools is in [http://eis.services.openoffice.org/EIS2/cws.ShowCWS?logon=true&amp;Id=2959&amp;Path=SRC680%2Fmdbdriver02 alpha state], and still has serious shortcomings. The project itself is currently stalled, nobody is actively working on it. Also, nobody is working on doing a reverse-engineering of the MSA file format. If somebody wants to do this, we should seriously investigate whether it makes more sense to support and improve existing reverse engineering efforts, namely MDB-Tools.<br /> <br /> ==Application, Chart2==<br /> * Description of the Chart2 module: [http://graphics.openoffice.org/chart/chart2codestructure.html Code Structure of chart2]<br /> <br /> ==General Questions==<br /> * Which are the common threads started at start up time and used by all OOo applications at runtime, and what are their functions? ([[KR]])?<br /> : A first over regarding the threads can be found here: [[Effort/Implement_Basic_Threading-Architecture#Threads]] More to come ...<br /> * Structure of VCL? See [[Sort_of_documentation_about_VCL_around_Native_Mac_OS_X_port]]<br /> ** A general overview about VCL was created by Eric Bachard, please have a look [http://wiki.services.openoffice.org/wiki/User:Ericb#Sort_of_documentation_about_VCL_around_Native_Mac_OS_X_port here]<br /> * [[TextRenderingProcess|Text rendering process]]<br /> * Memory Management (MT/MHU)<br /> * How to improve stability, and where to start? Beside doing thorough QA, you might use tools like [http://tools.www.openoffice.org/debugging/usingvalgrind.sxw Valgrind] or [http://tools.openoffice.org/files/documents/15/872/BoundsChecker.html BoundsChecker]<br /> * How to improve performance, and where to start? Use a [http://en.wikipedia.org/wiki/Performance_analysis profiler] to analyze the runtime behavior of the code that you want to improve.<br /> * Which code of OOo is responsible for the VBA Macro parse? How are they implemented?<br /> ** This is done by a hard coded parser in basic/source/comp<br /> * How is the code implemented to fulfill the specification of Unicode and gb2312 (SB): Follow the source code links for &amp;ldquo;UTF7&amp;ldquo; and &amp;ldquo;UTF8&amp;ldquo; (Unicode) and &amp;ldquo;EUC_CN&amp;rdquo; (GB2312) in [http://porting.openoffice.org/source/browse/porting/sal/textenc/textenc.cxx?rev=1.6&amp;view=markup sal/textenc/textenc.cxx:1.6].<br /> * How/where is the Boost library used? See [[boost]] for an overview.<br /> * The process of SVG protraction and SVG parse. The relationship between controller protraction and the resource of the controller. (SJ)<br /> * Mozilla and ActiveX plugins (MAV)<br /> * Which internet protocols are supported in OOo, and what can be improved to the network ability of OOo? (KSO)<br /> <br /> ==Feature Questions==<br /> * Currently a document can only be processed by one of the OOo applications - what about having just one application processing all kind of documents?<br /> * Are there any plans to integrate a desktop search engine? (Could be done as an extension)<br /> * Any plans to introduce classes comparable to CObject and CWinApp in MFC? (???)<br /> <br /> <br /> [[Category:FAQ]]<br /> [[Category:Developer_Documentation]]</div>

Mav https://wiki.openoffice.org/w/index.php?title=Developers_FAQ&diff=39332 2007-07-16T12:55:33Z

<p>Mav: </p> <hr /> <div>The Developers FAQ is a collection from different questions asked by Developers who are new to OpenOffice.org:<br /> <br /> This is work in progress, the developer mentioned behind the question will write the answer soon.<br /> <br /> <br /> ==Framework==<br /> * Description of the SFX2 framework? (MBA)<br /> * There are the roles of the different shells and views? See [[Framework/Article/Implementation_of_the_Dispatch_API_In_SFX2|Implementation of the Dispatch API In SFX2]]<br /> * Explanation of the dispatch/interceptor mechanism / command handling? See [[Framework/Article/Implementation_of_the_Dispatch_API_In_SFX2|Implementation of the Dispatch API In SFX2]]<br /> * How is the slot mechanism implemented, and how is the listener and broadcast mechanism implemented? See [[Framework/Article/Implementation_of_the_Dispatch_API_In_SFX2|Implementation of the Dispatch API In SFX2]]<br /> * Generic user interface: How does the framework implement the interface management, how to load toolbar, and how to implement berth area? See [[Framework/Article/General_Architecture_Of_The_Framework_User_Interface_Implementation|General Architecture of the Framework User Interface]]<br /> * Filter configuration<br /> ** [http://api.openoffice.org/docs/DevelopersGuide/OfficeDev/OfficeDev.xhtml#1_2_4_Integrating_Import_and_Export_Filters Developer&#039;s Guide 7.2.4 Integrating Import and Export Filters]<br /> ** Note: Description of the used configuration format in XML is outdated.<br /> * API for accessing OOo package format<br /> ** http://api.openoffice.org/docs/common/ref/com/sun/star/embed/Storage.html<br /> * Embedding<br /> ** http://wiki.services.openoffice.org/wiki/Framework/Article/General_Architecture_Of_Documents_Embedding<br /> * Templates (MAV)<br /> * Add-ons / Extensions support<br /> ** [[Framework/WorkInProgress/Addon_Menu_Toolbar_Merging|Support merging into the Office menu bar/toolbars.]]<br /> ** [[Framework/Article/Generic_UNO_Interfaces_for_complex_toolbar_controls|Complex toolbar controls for add-ons.]]<br /> ** [http://api.openoffice.org/docs/DevelopersGuide/Components/Components.xhtml#1_7_3_Add-Ons Developer&#039;s Guide 4.7.3 Add-ons]<br /> ** Add-on examples with sources (http://framework.openoffice.org/servlets/ProjectDocumentList?folderID=226&amp;expandFolder=226&amp;folderID=72) <br /> * The general part of the document storing/loading process (MAV)<br /> <br /> ==[http://udk.openoffice.org UDK]==<br /> * Mechanisms of Multi-Platform support ([[KR]]) <br /> :I assume this means multiple language support, please see [[Uno/Article/Working_with_Environments%2C_Mappings_%26_Objects|Working with Environments, Mappings &amp; Objects]] .<br /> * How to communicate with other OOo components, and how to implement a bridge ([[KR]]) <br /> : There is a tutorial for implementing C++ bridges, please see http://udk.openoffice.org/cpp/man/cpp_bridges.html . Most [[Uno/Binary|Binary Uno]] bridges are implemented in the [[Uno/Binary/Module/bridges|bridges]] module.<br /> * [[Uno/PyUno|Python Uno]] components may be run within the OOo process - how can they be called from [[Java]], [[C++]] or [[BASIC|StarBasic]]? ([[KR]])<br /> : [[Uno/PyUno|Python Uno]] components may be accessed like any other component, e.g. by doing a &quot;createInstance&quot; with a service which is implemented in [[Uno/PyUno|Python Uno]].<br /> * The relationship between [[Uno]], COM+, CORBA ([[KR]])<br /> : For a comparison between [[Uno]] and CORBA please see http://udk.openoffice.org/common/man/comparison_uno_corba.html , though [[Uno]] nowadays does support multiple inheritance. Also there was an effort, which unfortunately did not complete, do implement a [[Uno]] CORBA bridge, please see http://udk.openoffice.org/common/man/concept/uno_corba.html .<br /> : There is no document regarding [[Uno]] and (D)COM+. [[Uno]] has some similarities with COM+:<br /> :* &quot;queryInterface&quot;<br /> :* Language agnostic<br /> :* &quot;Apartments&quot;, please see the [[Uno/Spec/Threading-Model|Uno Threading-Model]] for details.<br /> :* Components<br /> :* Remote transparency<br /> <br /> ==Application, Writer==<br /> * Structure of tables? [[Writer_Core_And_Layout]]<br /> * Mechanism/Implementation of Undo? [[Writer_Core_And_Layout]]<br /> * Mechanism/Implementation of Frames, relationship? [[Writer_Core_And_Layout]]<br /> * Class structure of SwNode, SwNodes, SwNodeIndex, ..., relationship? [[Writer_Core_And_Layout]]<br /> * The relationship between the class ViewShell and SwDoc (OS)<br /> The ViewShell is created as indirect member of the SwPagePreview or as base class of SwWrtShell, SwFEShell, SwEditShell, SwCrsrShell as member of the SwView. This stack of shells provides access from SwView/SwPagePreview to the document. The ViewShell mostly for output (printing, painting) and the others for cursor travelling and content modification.<br /> <br /> ==Application, Draw/Impress==<br /> * The mechanism of slide show and animation (what is the difference between before and after)?<br /> ** The slideshow itself, and all animation functionality are implemented in the [[Slideshow]] module. (What is the meeaing of &quot;before&quot; and &quot;after&quot; in the context of this question?)<br /> * Copy&amp;Paste: Memory structure of clipboard in SD, difference between coping objects inside slides and coping objects from or into other applications like SW, SC? <br /> ** Clipboard between the same application type is done by using core implementations. Clipboard between different application types is done by using xml.<br /> * Mechanism of designing and implementation of master page and layout style in presentation (CL)<br /> ** Master pages and layout styles are already implemented in OOo.<br /> <br /> * Flash Export: (CL)<br /> ** Difference between the export of the simple character and the complex character?<br /> *** Simple characters are exported using the font tags of the flash format, complex characters are exported as polygons.<br /> ** The implementation of the Polygon in VCL. Such as the EM square，Body，Ascent and Descent to realize of the glyph?<br /> *** This question needs more data as the implementation of the Polygon in VCl itself has nothing to do with glyphs. It is only used to represend glyphs.<br /> ** The custom animation will be lost after the slides being exported into the swf. What cause it? There is no support to export the animation, is there? Do you have any plan to consummate it? And what&#039;s your purpose in this area?<br /> *** It is caused by the absence of an implementation that exports this particular feature. There is currently no assigned developer for the task to add this feature to the flash export. One developer from Redflag is activly contributing to the flash export.<br /> <br /> ==Application, Calc==<br /> * How are the areas for charts recognized, and how does the update notification work? (NN)<br /> ** Note that much of this has changed for the new chart. Don&#039;t make any changes based on older versions (before SRC680m213).<br /> ** The chart implementation uses the UNO API (XDataProvider) to get data sequence objects for each data series, and registers itself as modify listener with these objects.<br /> ** For the time when a chart object hasn&#039;t been loaded yet, Calc has its own internal listener (ScChartListener) to load the chart if its data is changed.<br /> * Relationship between cells, sheets and workbooks (class diagram) (NN)<br /> ** The core implementation of the document is class ScDocument. It has an array of pointers to ScTable (implementation of a sheet). Each sheet has a fixed-size array of ScColumn objects. Each ScColumn object holds the cells in one column.<br /> ** The cells are implemented by base class ScBaseCell and derived classes:<br /> *** ScNoteCell (empty except for note and listeners)<br /> *** ScValueCell (constant numeric value)<br /> *** ScStringCell (simple text)<br /> *** ScEditCell (formatted or multi-paragraph text)<br /> *** ScFormulaCell (formula)<br /> * Copy&amp;Paste: What&#039;s happening on Copy directly, and later if someone pastes into same spreadsheet or other application (NN)<br /> ** Implementation of copy for cells is at ScViewFunc::CopyToClip. The cells are copied into an internal object (ScDocument), then a ScTransferObj is created as the interface to the clipboard.<br /> ** Pasting into Calc copies the cells directly from the internal ScDocument object. Clipboard data in other formats for external applications is created on demand by ScTransferObj (ScTransferObj::GetData).<br /> <br /> ==Application, Database==<br /> * Why was the dbase driver engineered into file_based driver? And compared with the text/csv driver, what are the advantages of it in OOo&#039;s database, and how it was being designed in OOo&#039;s database?<br /> ** The &quot;file&quot; driver is not an own driver, it&#039;s a framework for, well, file-based databases, where a single file represents a table, and all such files in a given directory comprise the database. Both the text/csv driver and the dBase driver use this framework.<br /> ** The advantage of the dBase driver over the text/csv driver is that the former can read dBase files, while the latter can&#039;t.<br /> ** What do you mean with &quot;was being designed&quot;?<br /> * What are the project&#039;s short-term plan or the direction of development now?<br /> ** There are two areas which we currently mainly focus on: The new report designer which will be part of OpenOffice.org 2.3, and improved programmability of Base, where the first step is to allow embedding macros in database document.<br /> * In the project named &quot;Native, cross-platform access to MS Access databases&quot;, what is the current solution? Is there anyone beginning to re-engineer the MDB format himself?<br /> ** The current solution is employing [http://mdbtools.sourceforge.net/ MDB-Tools], a third-party product which allows access to .mdb files. The driver based on MDB-Tools is in [http://eis.services.openoffice.org/EIS2/cws.ShowCWS?logon=true&amp;Id=2959&amp;Path=SRC680%2Fmdbdriver02 alpha state], and still has serious shortcomings. The project itself is currently stalled, nobody is actively working on it. Also, nobody is working on doing a reverse-engineering of the MSA file format. If somebody wants to do this, we should seriously investigate whether it makes more sense to support and improve existing reverse engineering efforts, namely MDB-Tools.<br /> <br /> ==Application, Chart2==<br /> * Description of the Chart2 module: [http://graphics.openoffice.org/chart/chart2codestructure.html Code Structure of chart2]<br /> <br /> ==General Questions==<br /> * Which are the common threads started at start up time and used by all OOo applications at runtime, and what are their functions? ([[KR]])?<br /> : A first over regarding the threads can be found here: [[Effort/Implement_Basic_Threading-Architecture#Threads]] More to come ...<br /> * Structure of VCL? See [[Sort_of_documentation_about_VCL_around_Native_Mac_OS_X_port]]<br /> ** A general overview about VCL was created by Eric Bachard, please have a look [http://wiki.services.openoffice.org/wiki/User:Ericb#Sort_of_documentation_about_VCL_around_Native_Mac_OS_X_port here]<br /> * [[TextRenderingProcess|Text rendering process]]<br /> * Memory Management (MT/MHU)<br /> * How to improve stability, and where to start? Beside doing thorough QA, you might use tools like [http://tools.www.openoffice.org/debugging/usingvalgrind.sxw Valgrind] or [http://tools.openoffice.org/files/documents/15/872/BoundsChecker.html BoundsChecker]<br /> * How to improve performance, and where to start? Use a [http://en.wikipedia.org/wiki/Performance_analysis profiler] to analyze the runtime behavior of the code that you want to improve.<br /> * Which code of OOo is responsible for the VBA Macro parse? How are they implemented?<br /> ** This is done by a hard coded parser in basic/source/comp<br /> * How is the code implemented to fulfill the specification of Unicode and gb2312 (SB): Follow the source code links for &amp;ldquo;UTF7&amp;ldquo; and &amp;ldquo;UTF8&amp;ldquo; (Unicode) and &amp;ldquo;EUC_CN&amp;rdquo; (GB2312) in [http://porting.openoffice.org/source/browse/porting/sal/textenc/textenc.cxx?rev=1.6&amp;view=markup sal/textenc/textenc.cxx:1.6].<br /> * How/where is the Boost library used? See [[boost]] for an overview.<br /> * The process of SVG protraction and SVG parse. The relationship between controller protraction and the resource of the controller. (SJ)<br /> * Mozilla and ActiveX plugins (MAV)<br /> * Which internet protocols are supported in OOo, and what can be improved to the network ability of OOo? (KSO)<br /> <br /> ==Feature Questions==<br /> * Currently a document can only be processed by one of the OOo applications - what about having just one application processing all kind of documents?<br /> * Are there any plans to integrate a desktop search engine? (Could be done as an extension)<br /> * Any plans to introduce classes comparable to CObject and CWinApp in MFC? (???)<br /> <br /> <br /> [[Category:FAQ]]<br /> [[Category:Developer_Documentation]]</div>

Mav https://wiki.openoffice.org/w/index.php?title=Framework/Article/General_Architecture_Of_Documents_Embedding&diff=39331 2007-07-16T12:54:54Z

<p>Mav: </p> <hr /> <div>This article is a very short description of the general architecture of the documents embedding in OpenOffice.org2.x from API point of view.<br /> <br /> == The access to an embedded objects in document ==<br /> <br /> The following articles could be helpful to understand the possibilities to access embedded objects from different document types, the documentation is a little bit outdated so please see the comments to each link.<br /> <br /> * [http://api.openoffice.org/docs/DevelopersGuide/Text/Text.xhtml#1_3_10_3_Embedded_Objects Embedded objects in Writer document]<br /> ** Starting from OpenOffice.org2.1 it is possible to use [http://api.openoffice.org/docs/common/ref/com/sun/star/document/XEmbeddedObjectSupplier2.html com.sun.star.document.XEmbeddedObjectSupplier2] interface to get access to the object using the new embedding API<br /> * [http://api.openoffice.org/docs/DevelopersGuide/Charts/Charts.xhtml#1_2_1_2_Creating_a_Chart_OLE_Object_in_Draw_and_Impress Embedded chart in Draw and Impress documents]<br /> ** Other types of embedded objects can be inserted in the same way, it is enough just to use the different Class ID.<br /> ** Similar way can be used to insert/access the objects in Calc<br /> ** Starting from OpenOffice.org2.1 it is possible to get access to the new embedding API using &quot;EmbeddedObject&quot; property<br /> <br /> The main interface implemented by any embedded object and allowing to control the embedded object is [http://api.openoffice.org/docs/common/ref/com/sun/star/embed/XEmbeddedObject.html com.sun.star.embed.XEmbeddedObject]. Please see the API documentation for more details.</div>

Mav https://wiki.openoffice.org/w/index.php?title=Framework/Article/General_Architecture_Of_Documents_Embedding&diff=39330 2007-07-16T12:53:10Z

<p>Mav: </p> <hr /> <div>This article is a very short description of the general architecture of the documents embedding in OpenOffice.org2.x from API point of view.<br /> <br /> == The access to an embedded objects in document ==<br /> <br /> The following articles could be helpful to understand the possibilities to access embedded objects from different document types<br /> * [http://api.openoffice.org/docs/DevelopersGuide/Text/Text.xhtml#1_3_10_3_Embedded_Objects Embedded objects in Writer document]<br /> ** Starting from OpenOffice.org2.1 it is possible to use [http://api.openoffice.org/docs/common/ref/com/sun/star/document/XEmbeddedObjectSupplier2.html com.sun.star.document.XEmbeddedObjectSupplier2] interface to get access to the object using the new embedding API<br /> * [http://api.openoffice.org/docs/DevelopersGuide/Charts/Charts.xhtml#1_2_1_2_Creating_a_Chart_OLE_Object_in_Draw_and_Impress Embedded chart in Draw and Impress documents]<br /> ** Other types of embedded objects can be inserted in the same way, it is enough just to use the different Class ID.<br /> ** Similar way can be used to insert/access the objects in Calc<br /> ** Starting from OpenOffice.org2.1 it is possible to get access to the new embedding API using &quot;EmbeddedObject&quot; property<br /> <br /> The main interface implemented by any embedded object and allowing to control the embedded object is [http://api.openoffice.org/docs/common/ref/com/sun/star/embed/XEmbeddedObject.html com.sun.star.embed.XEmbeddedObject]. Please see the API documentation for more details.</div>

Mav https://wiki.openoffice.org/w/index.php?title=Developers_FAQ&diff=38785 2007-07-13T14:23:37Z

<p>Mav: </p> <hr /> <div>The Developers FAQ is a collection from different questions asked by Developers who are new to OpenOffice.org:<br /> <br /> This is work in progress, the developer mentioned behind the question will write the answer soon.<br /> <br /> <br /> ==Framework==<br /> * Description of the SFX2 framework? (MBA)<br /> * There are the roles of the different shells and views? See [[Framework/Article/Implementation_of_the_Dispatch_API_In_SFX2|Implementation of the Dispatch API In SFX2]]<br /> * Explanation of the dispatch/interceptor mechanism / command handling? See [[Framework/Article/Implementation_of_the_Dispatch_API_In_SFX2|Implementation of the Dispatch API In SFX2]]<br /> * How is the slot mechanism implemented, and how is the listener and broadcast mechanism implemented? See [[Framework/Article/Implementation_of_the_Dispatch_API_In_SFX2|Implementation of the Dispatch API In SFX2]]<br /> * Generic user interface: How does the framework implement the interface management, how to load toolbar, and how to implement berth area? See [[Framework/Article/General_Architecture_Of_The_Framework_User_Interface_Implementation|General Architecture of the Framework User Interface]]<br /> * Filter configuration<br /> ** [http://api.openoffice.org/docs/DevelopersGuide/OfficeDev/OfficeDev.xhtml#1_2_4_Integrating_Import_and_Export_Filters Developer&#039;s Guide 7.2.4 Integrating Import and Export Filters]<br /> ** Note: Description of the used configuration format in XML is outdated.<br /> * API for accessing OOo package format<br /> ** http://api.openoffice.org/docs/common/ref/com/sun/star/embed/Storage.html<br /> * Embedding (MAV)<br /> * Templates (MAV)<br /> * Add-ons / Extensions support<br /> ** [[Framework/WorkInProgress/Addon_Menu_Toolbar_Merging|Support merging into the Office menu bar/toolbars.]]<br /> ** [[Framework/Article/Generic_UNO_Interfaces_for_complex_toolbar_controls|Complex toolbar controls for add-ons.]]<br /> ** [http://api.openoffice.org/docs/DevelopersGuide/Components/Components.xhtml#1_7_3_Add-Ons Developer&#039;s Guide 4.7.3 Add-ons]<br /> ** Add-on examples with sources (http://framework.openoffice.org/servlets/ProjectDocumentList?folderID=226&amp;expandFolder=226&amp;folderID=72) <br /> * The general part of the document storing/loading process (MAV)<br /> <br /> ==[http://udk.openoffice.org UDK]==<br /> * Mechanisms of Multi-Platform support ([[KR]]) <br /> :I assume this means multiple language support, please see [[Uno/Article/Working_with_Environments%2C_Mappings_%26_Objects|Working with Environments, Mappings &amp; Objects]] .<br /> * How to communicate with other OOo components, and how to implement a bridge ([[KR]]) <br /> : There is a tutorial for implementing C++ bridges, please see http://udk.openoffice.org/cpp/man/cpp_bridges.html . Most [[Uno/Binary|Binary Uno]] bridges are implemented in the [[Uno/Binary/Module/bridges|bridges]] module.<br /> * [[Uno/PyUno|Python Uno]] components may be run within the OOo process - how can they be called from [[Java]], [[C++]] or [[BASIC|StarBasic]]? ([[KR]])<br /> : [[Uno/PyUno|Python Uno]] components may be accessed like any other component, e.g. by doing a &quot;createInstance&quot; with a service which is implemented in [[Uno/PyUno|Python Uno]].<br /> * The relationship between [[Uno]], COM+, CORBA ([[KR]])<br /> : For a comparison between [[Uno]] and CORBA please see http://udk.openoffice.org/common/man/comparison_uno_corba.html , though [[Uno]] nowadays does support multiple inheritance. Also there was an effort, which unfortunately did not complete, do implement a [[Uno]] CORBA bridge, please see http://udk.openoffice.org/common/man/concept/uno_corba.html .<br /> : There is no document regarding [[Uno]] and (D)COM+. [[Uno]] has some similarities with COM+:<br /> :* &quot;queryInterface&quot;<br /> :* Language agnostic<br /> :* &quot;Apartments&quot;, please see the [[Uno/Spec/Threading-Model|Uno Threading-Model]] for details.<br /> :* Components<br /> :* Remote transparency<br /> <br /> ==Application, Writer==<br /> * Structure of tables? [[Writer_Core_And_Layout]]<br /> * Mechanism/Implementation of Undo? [[Writer_Core_And_Layout]]<br /> * Mechanism/Implementation of Frames, relationship? [[Writer_Core_And_Layout]]<br /> * Class structure of SwNode, SwNodes, SwNodeIndex, ..., relationship? [[Writer_Core_And_Layout]]<br /> * The relationship between the class ViewShell and SwDoc (OS)<br /> <br /> ==Application, Draw/Impress==<br /> * The mechanism of slide show and animation (what is the difference between before and after)?<br /> ** The slideshow itself, and all animation functionality are implemented in the [[Slideshow]] module. (What is the meeaing of &quot;before&quot; and &quot;after&quot; in the context of this question?)<br /> * Copy&amp;Paste: Memory structure of clipboard in SD, difference between coping objects inside slides and coping objects from or into other applications like SW, SC? <br /> ** Clipboard between the same application type is done by using core implementations. Clipboard between different application types is done by using xml.<br /> * Mechanism of designing and implementation of master page and layout style in presentation (CL)<br /> ** Master pages and layout styles are already implemented in OOo.<br /> <br /> * Flash Export: (CL)<br /> ** Difference between the export of the simple character and the complex character?<br /> *** Simple characters are exported using the font tags of the flash format, complex characters are exported as polygons.<br /> ** The implementation of the Polygon in VCL. Such as the EM square，Body，Ascent and Descent to realize of the glyph?<br /> *** This question needs more data as the implementation of the Polygon in VCl itself has nothing to do with glyphs. It is only used to represend glyphs.<br /> ** The custom animation will be lost after the slides being exported into the swf. What cause it? There is no support to export the animation, is there? Do you have any plan to consummate it? And what&#039;s your purpose in this area?<br /> *** It is caused by the absence of an implementation that exports this particular feature. There is currently no assigned developer for the task to add this feature to the flash export. One developer from Redflag is activly contributing to the flash export.<br /> <br /> ==Application, Calc==<br /> * How are the areas for charts recognized, and how does the update notification work? (NN)<br /> * Relationship between cells, sheets and workbooks (class diagram) (NN)<br /> * Copy&amp;Paste: What&#039;s happening on Copy directly, and later if someone pastes into same spreadsheet or other application (NN)<br /> <br /> ==Application, Database==<br /> * Why was the dbase driver engineered into file_based driver? And compared with the text/csv driver, what are the advantages of it in OOo&#039;s database, and how it was being designed in OOo&#039;s database?<br /> ** The &quot;file&quot; driver is not an own driver, it&#039;s a framework for, well, file-based databases, where a single file represents a table, and all such files in a given directory comprise the database. Both the text/csv driver and the dBase driver use this framework.<br /> ** The advantage of the dBase driver over the text/csv driver is that the former can read dBase files, while the latter can&#039;t.<br /> ** What do you mean with &quot;was being designed&quot;?<br /> * What are the project&#039;s short-term plan or the direction of development now?<br /> ** There are two areas which we currently mainly focus on: The new report designer which will be part of OpenOffice.org 2.3, and improved programmability of Base, where the first step is to allow embedding macros in database document.<br /> * In the project named &quot;Native, cross-platform access to MS Access databases&quot;, what is the current solution? Is there anyone beginning to re-engineer the MDB format himself?<br /> ** The current solution is employing [http://mdbtools.sourceforge.net/ MDB-Tools], a third-party product which allows access to .mdb files. The driver based on MDB-Tools is in [http://eis.services.openoffice.org/EIS2/cws.ShowCWS?logon=true&amp;Id=2959&amp;Path=SRC680%2Fmdbdriver02 alpha state], and still has serious shortcomings. The project itself is currently stalled, nobody is actively working on it. Also, nobody is working on doing a reverse-engineering of the MSA file format. If somebody wants to do this, we should seriously investigate whether it makes more sense to support and improve existing reverse engineering efforts, namely MDB-Tools.<br /> <br /> ==Application, Chart2==<br /> * Description of the Chart2 module: [http://graphics.openoffice.org/chart/chart2codestructure.html Code Structure of chart2]<br /> <br /> ==General Questions==<br /> * Which are the common threads started at start up time and used by all OOo applications at runtime, and what are their functions? ([[KR]])?<br /> : A first over regarding the threads can be found here: [[Effort/Implement_Basic_Threading-Architecture#Threads]] More to come ...<br /> * Structure of VCL? See [[Sort_of_documentation_about_VCL_around_Native_Mac_OS_X_port]]<br /> ** A general overview about VCL was created by Eric Bachard, please have a look [http://wiki.services.openoffice.org/wiki/User:Ericb#Sort_of_documentation_about_VCL_around_Native_Mac_OS_X_port here]<br /> * [[TextRenderingProcess|Text rendering process]]<br /> * Memory Management (MT/MHU)<br /> * How to improve stability, and where to start? Beside doing thorough QA, you might use tools like [http://tools.www.openoffice.org/debugging/usingvalgrind.sxw Valgrind] or [http://tools.openoffice.org/files/documents/15/872/BoundsChecker.html BoundsChecker]<br /> * How to improve performance, and where to start? Use a [http://en.wikipedia.org/wiki/Performance_analysis profiler] to analyze the runtime behavior of the code that you want to improve.<br /> * Which code of OOo is responsible for the VBA Macro parse? How are they implemented?<br /> ** This is done by a hard coded parser in basic/source/comp<br /> * How is the code implemented to fulfill the specification of Unicode and gb2312 (SB): Follow the source code links for &amp;ldquo;UTF7&amp;ldquo; and &amp;ldquo;UTF8&amp;ldquo; (Unicode) and &amp;ldquo;EUC_CN&amp;rdquo; (GB2312) in [http://porting.openoffice.org/source/browse/porting/sal/textenc/textenc.cxx?rev=1.6&amp;view=markup sal/textenc/textenc.cxx:1.6].<br /> * How/where is the Boost library used? See [[boost]] for an overview.<br /> * The process of SVG protraction and SVG parse. The relationship between controller protraction and the resource of the controller. (SJ)<br /> * Mozilla and ActiveX plugins (MAV)<br /> * Which internet protocols are supported in OOo, and what can be improved to the network ability of OOo? (KSO)<br /> <br /> ==Feature Questions==<br /> * Currently a document can only be processed by one of the OOo applications - what about having just one application processing all kind of documents?<br /> * Are there any plans to integrate a desktop search engine? (Could be done as an extension)<br /> * Any plans to introduce classes comparable to CObject and CWinApp in MFC? (???)<br /> <br /> <br /> [[Category:FAQ]]<br /> [[Category:Developer_Documentation]]</div>

Mav https://wiki.openoffice.org/w/index.php?title=Developers_FAQ&diff=38783 2007-07-13T14:19:47Z

<p>Mav: </p> <hr /> <div>The Developers FAQ is a collection from different questions asked by Developers who are new to OpenOffice.org:<br /> <br /> This is work in progress, the developer mentioned behind the question will write the answer soon.<br /> <br /> <br /> ==Framework==<br /> * Description of the SFX2 framework? (MBA)<br /> * There are the roles of the different shells and views? See [[Framework/Article/Implementation_of_the_Dispatch_API_In_SFX2|Implementation of the Dispatch API In SFX2]]<br /> * Explanation of the dispatch/interceptor mechanism / command handling? See [[Framework/Article/Implementation_of_the_Dispatch_API_In_SFX2|Implementation of the Dispatch API In SFX2]]<br /> * How is the slot mechanism implemented, and how is the listener and broadcast mechanism implemented? See [[Framework/Article/Implementation_of_the_Dispatch_API_In_SFX2|Implementation of the Dispatch API In SFX2]]<br /> * Generic user interface: How does the framework implement the interface management, how to load toolbar, and how to implement berth area? See [[Framework/Article/General_Architecture_Of_The_Framework_User_Interface_Implementation|General Architecture of the Framework User Interface]]<br /> * Filter configuration<br /> ** [http://api.openoffice.org/docs/DevelopersGuide/OfficeDev/OfficeDev.xhtml#1_2_4_Integrating_Import_and_Export_Filters Developer&#039;s Guide 7.2.4 Integrating Import and Export Filters]<br /> ** Note: Description of the used configuration format in XML is outdated.<br /> * API for accessing OOo package format<br /> ** [http://api.openoffice.org/docs/common/ref/com/sun/star/embed/Storage.html]<br /> * Embedding (MAV)<br /> * Templates (MAV)<br /> * Add-ons / Extensions support<br /> ** [[Framework/WorkInProgress/Addon_Menu_Toolbar_Merging|Support merging into the Office menu bar/toolbars.]]<br /> ** [[Framework/Article/Generic_UNO_Interfaces_for_complex_toolbar_controls|Complex toolbar controls for add-ons.]]<br /> ** [http://api.openoffice.org/docs/DevelopersGuide/Components/Components.xhtml#1_7_3_Add-Ons Developer&#039;s Guide 4.7.3 Add-ons]<br /> ** Add-on examples with sources (http://framework.openoffice.org/servlets/ProjectDocumentList?folderID=226&amp;expandFolder=226&amp;folderID=72) <br /> * The general part of the document storing/loading process (MAV)<br /> <br /> ==[http://udk.openoffice.org UDK]==<br /> * Mechanisms of Multi-Platform support ([[KR]]) <br /> :I assume this means multiple language support, please see [[Uno/Article/Working_with_Environments%2C_Mappings_%26_Objects|Working with Environments, Mappings &amp; Objects]] .<br /> * How to communicate with other OOo components, and how to implement a bridge ([[KR]]) <br /> : There is a tutorial for implementing C++ bridges, please see http://udk.openoffice.org/cpp/man/cpp_bridges.html . Most [[Uno/Binary|Binary Uno]] bridges are implemented in the [[Uno/Binary/Module/bridges|bridges]] module.<br /> * [[Uno/PyUno|Python Uno]] components may be run within the OOo process - how can they be called from [[Java]], [[C++]] or [[BASIC|StarBasic]]? ([[KR]])<br /> : [[Uno/PyUno|Python Uno]] components may be accessed like any other component, e.g. by doing a &quot;createInstance&quot; with a service which is implemented in [[Uno/PyUno|Python Uno]].<br /> * The relationship between [[Uno]], COM+, CORBA ([[KR]])<br /> : For a comparison between [[Uno]] and CORBA please see http://udk.openoffice.org/common/man/comparison_uno_corba.html , though [[Uno]] nowadays does support multiple inheritance. Also there was an effort, which unfortunately did not complete, do implement a [[Uno]] CORBA bridge, please see http://udk.openoffice.org/common/man/concept/uno_corba.html .<br /> : There is no document regarding [[Uno]] and (D)COM+. [[Uno]] has some similarities with COM+:<br /> :* &quot;queryInterface&quot;<br /> :* Language agnostic<br /> :* &quot;Apartments&quot;, please see the [[Uno/Spec/Threading-Model|Uno Threading-Model]] for details.<br /> :* Components<br /> :* Remote transparency<br /> <br /> ==Application, Writer==<br /> * Structure of tables? [[Writer_Core_And_Layout]]<br /> * Mechanism/Implementation of Undo? [[Writer_Core_And_Layout]]<br /> * Mechanism/Implementation of Frames, relationship? [[Writer_Core_And_Layout]]<br /> * Class structure of SwNode, SwNodes, SwNodeIndex, ..., relationship? [[Writer_Core_And_Layout]]<br /> * The relationship between the class ViewShell and SwDoc (OS)<br /> <br /> ==Application, Draw/Impress==<br /> * The mechanism of slide show and animation (what is the difference between before and after)?<br /> ** The slideshow itself, and all animation functionality are implemented in the [[Slideshow]] module. (What is the meeaing of &quot;before&quot; and &quot;after&quot; in the context of this question?)<br /> * Copy&amp;Paste: Memory structure of clipboard in SD, difference between coping objects inside slides and coping objects from or into other applications like SW, SC? <br /> ** Clipboard between the same application type is done by using core implementations. Clipboard between different application types is done by using xml.<br /> * Mechanism of designing and implementation of master page and layout style in presentation (CL)<br /> ** Master pages and layout styles are already implemented in OOo.<br /> <br /> * Flash Export: (CL)<br /> ** Difference between the export of the simple character and the complex character?<br /> *** Simple characters are exported using the font tags of the flash format, complex characters are exported as polygons.<br /> ** The implementation of the Polygon in VCL. Such as the EM square，Body，Ascent and Descent to realize of the glyph?<br /> *** This question needs more data as the implementation of the Polygon in VCl itself has nothing to do with glyphs. It is only used to represend glyphs.<br /> ** The custom animation will be lost after the slides being exported into the swf. What cause it? There is no support to export the animation, is there? Do you have any plan to consummate it? And what&#039;s your purpose in this area?<br /> *** It is caused by the absence of an implementation that exports this particular feature. There is currently no assigned developer for the task to add this feature to the flash export. One developer from Redflag is activly contributing to the flash export.<br /> <br /> ==Application, Calc==<br /> * How are the areas for charts recognized, and how does the update notification work? (NN)<br /> * Relationship between cells, sheets and workbooks (class diagram) (NN)<br /> * Copy&amp;Paste: What&#039;s happening on Copy directly, and later if someone pastes into same spreadsheet or other application (NN)<br /> <br /> ==Application, Database==<br /> * Why was the dbase driver engineered into file_based driver? And compared with the text/csv driver, what are the advantages of it in OOo&#039;s database, and how it was being designed in OOo&#039;s database?<br /> ** The &quot;file&quot; driver is not an own driver, it&#039;s a framework for, well, file-based databases, where a single file represents a table, and all such files in a given directory comprise the database. Both the text/csv driver and the dBase driver use this framework.<br /> ** The advantage of the dBase driver over the text/csv driver is that the former can read dBase files, while the latter can&#039;t.<br /> ** What do you mean with &quot;was being designed&quot;?<br /> * What are the project&#039;s short-term plan or the direction of development now?<br /> ** There are two areas which we currently mainly focus on: The new report designer which will be part of OpenOffice.org 2.3, and improved programmability of Base, where the first step is to allow embedding macros in database document.<br /> * In the project named &quot;Native, cross-platform access to MS Access databases&quot;, what is the current solution? Is there anyone beginning to re-engineer the MDB format himself?<br /> ** The current solution is employing [http://mdbtools.sourceforge.net/ MDB-Tools], a third-party product which allows access to .mdb files. The driver based on MDB-Tools is in [http://eis.services.openoffice.org/EIS2/cws.ShowCWS?logon=true&amp;Id=2959&amp;Path=SRC680%2Fmdbdriver02 alpha state], and still has serious shortcomings. The project itself is currently stalled, nobody is actively working on it. Also, nobody is working on doing a reverse-engineering of the MSA file format. If somebody wants to do this, we should seriously investigate whether it makes more sense to support and improve existing reverse engineering efforts, namely MDB-Tools.<br /> <br /> ==Application, Chart2==<br /> * Description of the Chart2 module: [http://graphics.openoffice.org/chart/chart2codestructure.html Code Structure of chart2]<br /> <br /> ==General Questions==<br /> * Which are the common threads started at start up time and used by all OOo applications at runtime, and what are their functions? ([[KR]])?<br /> : A first over regarding the threads can be found here: [[Effort/Implement_Basic_Threading-Architecture#Threads]] More to come ...<br /> * Structure of VCL? See [[Sort_of_documentation_about_VCL_around_Native_Mac_OS_X_port]]<br /> ** A general overview about VCL was created by Eric Bachard, please have a look [http://wiki.services.openoffice.org/wiki/User:Ericb#Sort_of_documentation_about_VCL_around_Native_Mac_OS_X_port here]<br /> * [[TextRenderingProcess|Text rendering process]]<br /> * Memory Management (MT/MHU)<br /> * How to improve stability, and where to start? Beside doing thorough QA, you might use tools like [http://tools.www.openoffice.org/debugging/usingvalgrind.sxw Valgrind] or [http://tools.openoffice.org/files/documents/15/872/BoundsChecker.html BoundsChecker]<br /> * How to improve performance, and where to start? Use a [http://en.wikipedia.org/wiki/Performance_analysis profiler] to analyze the runtime behavior of the code that you want to improve.<br /> * Which code of OOo is responsible for the VBA Macro parse? How are they implemented?<br /> ** This is done by a hard coded parser in basic/source/comp<br /> * How is the code implemented to fulfill the specification of Unicode and gb2312 (SB): Follow the source code links for &amp;ldquo;UTF7&amp;ldquo; and &amp;ldquo;UTF8&amp;ldquo; (Unicode) and &amp;ldquo;EUC_CN&amp;rdquo; (GB2312) in [http://porting.openoffice.org/source/browse/porting/sal/textenc/textenc.cxx?rev=1.6&amp;view=markup sal/textenc/textenc.cxx:1.6].<br /> * How/where is the Boost library used? See [[boost]] for an overview.<br /> * The process of SVG protraction and SVG parse. The relationship between controller protraction and the resource of the controller. (SJ)<br /> * Mozilla and ActiveX plugins (MAV)<br /> * Which internet protocols are supported in OOo, and what can be improved to the network ability of OOo? (KSO)<br /> <br /> ==Feature Questions==<br /> * Currently a document can only be processed by one of the OOo applications - what about having just one application processing all kind of documents?<br /> * Are there any plans to integrate a desktop search engine? (Could be done as an extension)<br /> * Any plans to introduce classes comparable to CObject and CWinApp in MFC? (???)<br /> <br /> <br /> [[Category:FAQ]]<br /> [[Category:Developer_Documentation]]</div>

Mav