Build failed in Jenkins: PDFBox-sonar #312

2017-11-19 Thread Apache Jenkins Server
See 


Changes:

[tilman] PDFBOX-2852: improve javadoc

--
[...truncated 197.68 KB...]
[INFO] JaCoCoSensor: JaCoCo report not found : 

[INFO] Sensor JaCoCoSensor (done) | time=0ms
[INFO] Sensor JaCoCoItSensor
[INFO] JaCoCoItSensor: JaCoCo IT report not found: 

[INFO] Sensor JaCoCoItSensor (done) | time=0ms
[INFO] Sensor JaCoCoOverallSensor
[INFO] Sensor JaCoCoOverallSensor (done) | time=0ms
[INFO] Sensor XmlFileSensor
[INFO] Sensor XmlFileSensor (done) | time=2ms
[INFO] Sensor Zero Coverage Sensor
[INFO] Sensor Zero Coverage Sensor (done) | time=8ms
[INFO] Sensor Code Colorizer Sensor
[INFO] Sensor Code Colorizer Sensor (done) | time=2ms
[INFO] Sensor CPD Block Indexer
[INFO] JavaCpdBlockIndexer is used for java
[INFO] Sensor CPD Block Indexer (done) | time=84ms
[INFO] -  Scan Apache PDFBox tools
[INFO] Base dir: 
[INFO] Working dir: 

[INFO] Source paths: pom.xml, src/main/java
[INFO] Test paths: src/test/java
[INFO] Binary dirs: target/classes
[INFO] Source encoding: UTF-8, default locale: en_US
[INFO] Index files
[INFO] 27 files indexed
[INFO] Quality profile for java: Sonar way
[INFO] Sensor Lines Sensor
[INFO] Sensor Lines Sensor (done) | time=0ms
[INFO] Sensor JavaSquidSensor
[INFO] Configured Java source version (sonar.java.source): 7
[INFO] JavaClasspath initialization
[INFO] JavaClasspath initialization (done) | time=0ms
[INFO] JavaTestClasspath initialization
[INFO] JavaTestClasspath initialization (done) | time=0ms
[INFO] Java Main Files AST scan
[INFO] 23 source files to be analyzed
[INFO] Java Main Files AST scan (done) | time=4428ms
[INFO] Java Test Files AST scan
[INFO] 23/23 source files have been analyzed
[INFO] 4 source files to be analyzed
[INFO] Java Test Files AST scan (done) | time=112ms
[INFO] Sensor JavaSquidSensor (done) | time=4556ms
[INFO] Sensor SCM Sensor
[INFO] 4/4 source files have been analyzed
[INFO] Sensor SCM Sensor (done) | time=2ms
[INFO] Sensor Coverage Report Import
[INFO] Sensor Coverage Report Import (done) | time=0ms
[INFO] Sensor Coverage Report Import
[INFO] Sensor Coverage Report Import (done) | time=0ms
[INFO] Sensor Unit Test Results Import
[INFO] Sensor Unit Test Results Import (done) | time=0ms
[INFO] Sensor SurefireSensor
[INFO] parsing 

[INFO] Sensor SurefireSensor (done) | time=0ms
[INFO] Sensor JaCoCoSensor
[INFO] JaCoCoSensor: JaCoCo report not found : 

[INFO] Sensor JaCoCoSensor (done) | time=0ms
[INFO] Sensor JaCoCoItSensor
[INFO] JaCoCoItSensor: JaCoCo IT report not found: 

[INFO] Sensor JaCoCoItSensor (done) | time=0ms
[INFO] Sensor JaCoCoOverallSensor
[INFO] Sensor JaCoCoOverallSensor (done) | time=0ms
[INFO] Sensor XmlFileSensor
[INFO] Sensor XmlFileSensor (done) | time=0ms
[INFO] Sensor Zero Coverage Sensor
[INFO] Sensor Zero Coverage Sensor (done) | time=3ms
[INFO] Sensor Code Colorizer Sensor
[INFO] Sensor Code Colorizer Sensor (done) | time=0ms
[INFO] Sensor CPD Block Indexer
[INFO] JavaCpdBlockIndexer is used for java
[INFO] Sensor CPD Block Indexer (done) | time=29ms
[INFO] -  Scan Apache PDFBox application
[INFO] Base dir: 
[INFO] Working dir: 

[INFO] Source paths: pom.xml
[INFO] Binary dirs: target/classes
[INFO] Source encoding: UTF-8, default locale: en_US
[INFO] Index files
[INFO] 0 files indexed
[INFO] Sensor Lines Sensor
[INFO] Sensor Lines Sensor (done) | time=0ms
[INFO] Sensor SCM Sensor
[INFO] Sensor SCM Sensor (done) | time=0ms
[INFO] Sensor Coverage Report Import
[INFO] Sensor Coverage Report Import (done) | time=0ms
[INFO] Sensor Coverage Report Import
[INFO] Sensor Coverage Report Import (done) | time=0ms
[INFO] Sensor Unit Test Results Import
[INFO] Sensor Unit Test Results Import (done) | time=0ms
[INFO] Sensor XmlFileSensor
[INFO] Sensor XmlFileSensor (done) | time=0ms
[INFO] Sensor Zero Coverage Sensor
[INFO] Sensor Zero Coverage Sensor (done) | time=0ms
[INFO] Sensor Code Colorizer Sensor
[INFO] Sensor Code Colorizer Sensor (done) | time=1ms
[INFO] Sensor CPD Block Indexer
[INFO] Sensor CPD Block Indexer (done) | time=0ms
[INFO] -  Scan Apache PDFBox Debugger application
[INFO] Base dir: 

[INFO] Working dir: 

[jira] [Commented] (PDFBOX-2852) Improve code quality (2)

2017-11-19 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/PDFBOX-2852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258426#comment-16258426
 ] 

ASF subversion and git services commented on PDFBOX-2852:
-

Commit 1815720 from [~tilman] in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1815720 ]

PDFBOX-2852: improve javadoc

> Improve code quality (2)
> 
>
> Key: PDFBOX-2852
> URL: https://issues.apache.org/jira/browse/PDFBOX-2852
> Project: PDFBox
>  Issue Type: Task
>Affects Versions: 2.0.0
>Reporter: Tilman Hausherr
> Attachments: PDNameTreeNode.java.patch, StringBuffer.patch, 
> XMPSchema.java.patch, explicit_array_creation.patch, fix_javadoc.patch, 
> foreach.patch, foreach2.patch, generic_type_arguments.patch, noarray.patch, 
> semicolon.patch, stringbuilder.patch, unnecessary_type_casting.patch, 
> unused_imports.patch, usestatic.patch, winansiencoding.patch, 
> winansiencoding2.patch
>
>
> This is a longterm issue for the task to improve code quality, by using the 
> [SonarQube 
> report|https://analysis.apache.org/dashboard/index/org.apache.pdfbox:pdfbox-reactor],
>  hints in different IDEs, the FindBugs tool and other code quality tools.
> This is a follow-up of PDFBOX-2576, which was getting too long.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org



[jira] [Commented] (PDFBOX-2852) Improve code quality (2)

2017-11-19 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/PDFBOX-2852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258427#comment-16258427
 ] 

ASF subversion and git services commented on PDFBOX-2852:
-

Commit 1815721 from [~tilman] in branch 'pdfbox/branches/2.0'
[ https://svn.apache.org/r1815721 ]

PDFBOX-2852: improve javadoc

> Improve code quality (2)
> 
>
> Key: PDFBOX-2852
> URL: https://issues.apache.org/jira/browse/PDFBOX-2852
> Project: PDFBox
>  Issue Type: Task
>Affects Versions: 2.0.0
>Reporter: Tilman Hausherr
> Attachments: PDNameTreeNode.java.patch, StringBuffer.patch, 
> XMPSchema.java.patch, explicit_array_creation.patch, fix_javadoc.patch, 
> foreach.patch, foreach2.patch, generic_type_arguments.patch, noarray.patch, 
> semicolon.patch, stringbuilder.patch, unnecessary_type_casting.patch, 
> unused_imports.patch, usestatic.patch, winansiencoding.patch, 
> winansiencoding2.patch
>
>
> This is a longterm issue for the task to improve code quality, by using the 
> [SonarQube 
> report|https://analysis.apache.org/dashboard/index/org.apache.pdfbox:pdfbox-reactor],
>  hints in different IDEs, the FindBugs tool and other code quality tools.
> This is a follow-up of PDFBOX-2576, which was getting too long.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org



[jira] [Comment Edited] (PDFBOX-4014) Malformed/pathological/malicious input can lead to infinite looping

2017-11-19 Thread Tilman Hausherr (JIRA)

[ 
https://issues.apache.org/jira/browse/PDFBOX-4014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258408#comment-16258408
 ] 

Tilman Hausherr edited comment on PDFBOX-4014 at 11/19/17 9:56 AM:
---

I let it run and it was still working after a few minutes. I did check out the 
branch and I made sure that this is that library that is being used. The extra 
part in SymbolDictionary is hit once, the one in TextRegion never. 


was (Author: tilman):
I let it run and it was still working after a few minutes. I did check out the 
branch and I made sure that this is that file that is being used. The extra 
part in SymbolDictionary is hit once, the one in TextRegion never. 

> Malformed/pathological/malicious input can lead to infinite looping
> ---
>
> Key: PDFBOX-4014
> URL: https://issues.apache.org/jira/browse/PDFBOX-4014
> Project: PDFBox
>  Issue Type: Bug
>  Components: JBIG2
>Affects Versions: 3.0.0 JBIG2
>Reporter: Jörg Henne
>Assignee: Jörg Henne
>
> [~tilman] writes
> {quote}
> See this issue:
> https://bugs.chromium.org/p/chromium/issues/detail?id=450971
> look for "pdfium-loop2.pdf".
> I haven't created an issue, because this could be relevant to security.
> To reproduce the bug with PDFBox, do this:
>  PDDocument document = PDDocument.load(new 
> File("pdfium-loop2.pdf"));
>  new PDFRenderer(document).renderImage(0);
> For maven you need
> 
>  org.apache.pdfbox
>  pdfbox
>  2.0.8
> 
> and of course jbig2.
> {quote}
> An analysis shows that two circumstances contribute to the problem:
> # T.88 section E.2.10 specifies that MQ encoded data can be minimized if 
> trailing data contains "just boring stuff, i.e. 1-bits". Thus, an infinite 
> sequence of MQ encoded decisions can be encoded in a finite number of bytes.
> # T.88 section 6.4.5 3c specifies that the condition for terminating the 
> decoding of a text region strip is the occurrence of the OOB symbol as a 
> symbol's S coordinate.
> If a JBIG2 stream contains a strip that uses #1 yielding a stream of S 
> coordinates that never contain OOB during the decoding phase for #2, an 
> infinite loop results, as text region decoding has no other terminating 
> condition.
> The result is "just" a denial of service. No risk of buffer overruns etc. is 
> associated with the issue. 
> A similar issue exists with symbol dictionary decoding. However in this case 
> decoding will not enter an infinite loop due to an array index out of bounds 
> exception that is thrown once more symbols than expected have been decoded.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org



[jira] [Commented] (PDFBOX-4014) Malformed/pathological/malicious input can lead to infinite looping

2017-11-19 Thread Tilman Hausherr (JIRA)

[ 
https://issues.apache.org/jira/browse/PDFBOX-4014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258408#comment-16258408
 ] 

Tilman Hausherr commented on PDFBOX-4014:
-

I let it run and it was still working after a few minutes. I did check out the 
branch and I made sure that this is that file that is being used. The extra 
part in SymbolDictionary is hit once, the one in TextRegion never. 

> Malformed/pathological/malicious input can lead to infinite looping
> ---
>
> Key: PDFBOX-4014
> URL: https://issues.apache.org/jira/browse/PDFBOX-4014
> Project: PDFBox
>  Issue Type: Bug
>  Components: JBIG2
>Affects Versions: 3.0.0 JBIG2
>Reporter: Jörg Henne
>Assignee: Jörg Henne
>
> [~tilman] writes
> {quote}
> See this issue:
> https://bugs.chromium.org/p/chromium/issues/detail?id=450971
> look for "pdfium-loop2.pdf".
> I haven't created an issue, because this could be relevant to security.
> To reproduce the bug with PDFBox, do this:
>  PDDocument document = PDDocument.load(new 
> File("pdfium-loop2.pdf"));
>  new PDFRenderer(document).renderImage(0);
> For maven you need
> 
>  org.apache.pdfbox
>  pdfbox
>  2.0.8
> 
> and of course jbig2.
> {quote}
> An analysis shows that two circumstances contribute to the problem:
> # T.88 section E.2.10 specifies that MQ encoded data can be minimized if 
> trailing data contains "just boring stuff, i.e. 1-bits". Thus, an infinite 
> sequence of MQ encoded decisions can be encoded in a finite number of bytes.
> # T.88 section 6.4.5 3c specifies that the condition for terminating the 
> decoding of a text region strip is the occurrence of the OOB symbol as a 
> symbol's S coordinate.
> If a JBIG2 stream contains a strip that uses #1 yielding a stream of S 
> coordinates that never contain OOB during the decoding phase for #2, an 
> infinite loop results, as text region decoding has no other terminating 
> condition.
> The result is "just" a denial of service. No risk of buffer overruns etc. is 
> associated with the issue. 
> A similar issue exists with symbol dictionary decoding. However in this case 
> decoding will not enter an infinite loop due to an array index out of bounds 
> exception that is thrown once more symbols than expected have been decoded.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org



[jira] [Updated] (PDFBOX-4017) Symbol font glyphs not found on Windows 10 fall creators update

2017-11-19 Thread Tilman Hausherr (JIRA)

 [ 
https://issues.apache.org/jira/browse/PDFBOX-4017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tilman Hausherr updated PDFBOX-4017:

Description: 
Since the Windows 10 fall creators update all files with the Symbol standard 14 
font are no longer rendered properly. Seems to have something to do with a 
difference in the cmap subtable (all numbers start with F000) and a missing 
postscript table.

The font has two cmap subtables. The first one has codes that start with 0, the 
second one has codes that start with 0xF000. The code names we get from 
{{getUniNameOfCodePoint(unicodes.codePointAt(0))}} are NOT the low ones, only 
some match, those that are also in ascii.

For ">", there are two cmap subtables codes: for "Macintosh, Roman" it is 0x3e, 
for "Microsoft, Symbol" it is 0xf03e. I tried forcing the first table
{{code}}
cmap = cmapTable.getSubtable(CmapTable.PLATFORM_MACINTOSH, 0);
{{code}}
but many codes are missing, e.g. the greek alphabet.


For "eta" (looks like an "n")
pdf code 0150 = 0x68
unicode 0x3b7
windows code in charmap.exe: 68
code in subtables: 0x68 and 0xf068

lozenge
unicode 0x25ca
pdf code 0340 = 0xe0
code in subtables: 0x0e and 0xf0e0

So it seems one has to bypass this unicode thing and work directly with the 
symbol encoding...

Websites:
https://www.microsoft.com/typography/otspec/cmap.htm#windowsPlatform
https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6cmap.html

  was:
Since the Windows 10 fall creators update all files with the Symbol standard 14 
font are no longer rendered properly. Seems to have something to do with a 
difference in the cmap subtable (all numbers start with F000) and a missing 
postscript table.

...


> Symbol font glyphs not found on Windows 10 fall creators update
> ---
>
> Key: PDFBOX-4017
> URL: https://issues.apache.org/jira/browse/PDFBOX-4017
> Project: PDFBox
>  Issue Type: Bug
>  Components: FontBox, Rendering
>Affects Versions: 2.0.8
> Environment: Windows 10 fall creators update
>Reporter: Tilman Hausherr
>
> Since the Windows 10 fall creators update all files with the Symbol standard 
> 14 font are no longer rendered properly. Seems to have something to do with a 
> difference in the cmap subtable (all numbers start with F000) and a missing 
> postscript table.
> The font has two cmap subtables. The first one has codes that start with 0, 
> the second one has codes that start with 0xF000. The code names we get from 
> {{getUniNameOfCodePoint(unicodes.codePointAt(0))}} are NOT the low ones, only 
> some match, those that are also in ascii.
> For ">", there are two cmap subtables codes: for "Macintosh, Roman" it is 
> 0x3e, for "Microsoft, Symbol" it is 0xf03e. I tried forcing the first table
> {{code}}
> cmap = cmapTable.getSubtable(CmapTable.PLATFORM_MACINTOSH, 0);
> {{code}}
> but many codes are missing, e.g. the greek alphabet.
> For "eta" (looks like an "n")
> pdf code 0150 = 0x68
> unicode 0x3b7
> windows code in charmap.exe: 68
> code in subtables: 0x68 and 0xf068
> lozenge
> unicode 0x25ca
> pdf code 0340 = 0xe0
> code in subtables: 0x0e and 0xf0e0
> So it seems one has to bypass this unicode thing and work directly with the 
> symbol encoding...
> Websites:
> https://www.microsoft.com/typography/otspec/cmap.htm#windowsPlatform
> https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6cmap.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org