[Bug 62159] Support XML signature over windows certificate store

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=62159

Andreas Beeker  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #1 from Andreas Beeker  ---
applied via r1825948

inspired by https://stackoverflow.com/questions/48616473

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[Bug 62159] New: Support XML signature over windows certificate store

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=62159

Bug ID: 62159
   Summary: Support XML signature over windows certificate store
   Product: POI
   Version: 4.0-dev
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: OPC
  Assignee: dev@poi.apache.org
  Reporter: kiwiwi...@apache.org
  Target Milestone: ---

Up till it was not possible to use a windows certificate store entry to sign
OPC package, because the code expected the encoded format of the key.
Furthermore there were some SHA2 workarounds in place for a IBM JDK6, which is
now obsolete as we've upgraded to JDK8.

Using the windows keys is not straight forward, as the SunMSCAPI has some
surprises [1] - especially using the private key with the cipher api results
actually in signing it with the public key ... therefore the existing code
using the cipher api only works with keys derived from PKCS12 / JKS keystores.

I've refactored a few of the internals, but kept the documented convenience API
[2] as-is.

Another flaw I've discovered by testing the various hashes was, that XmlSec is
adding line-breaks to the digests when base64 encoded hash/digest is longer
than the base64 default line-length of 76 chars. This affects the hash with 64
bytes like SHA512 and Office marks the signature as invalid.
To workaround you need to set the following JVM property [3]:
-Dorg.apache.xml.security.ignoreLineBreaks=true

I haven't hardcoded that setting as I think this is a bad approach, i.e.
setting it in POI (+ security manager handling) is as worse as relying on a JVM
property to be set instead of providing an API for it ...


[1] https://stackoverflow.com/questions/39196145
[2] http://poi.apache.org/encryption.html#Signing+an+office+document
[3] https://bz.apache.org/bugzilla/show_bug.cgi?id=42061

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

Re: publishing poi xmlbeans jars

[pj.fanning]

My attempt at a short description of why we want to be able to patch
xmlbeans.

Apache Poi has a significant dependency on XmlBeans. There would need to be
a lot of work done to switch to an alternative (and this might happen at a
later date). We have identified a few issues in XmlBeans that we would like
to be fix and would like to be able to fix other high priority issues that
might be reported in future.



--
Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html

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

Re: publishing poi xmlbeans jars

[Dave Fisher]

Hi -

POI devs. Should we discuss quickly what it would mean to take on XMLBeans as a 
product of POI?

(1) Move code to a POI repository.
(2) Build.
(3) Get control of website.
(4) Release.

Alternatively others have suggested the following:
(A) Take XMLBeans to the Incubator doing the move and asking dependent projects 
if any dev would like to participate.
(B) Take XMLBeans to the Commons and make it a sub-module of Commons.

I think we have some urgency to move forward. It would help to have a 25 word 
description about why the project absolutely needs to do this.

Let me know.

Regards,
Dave

> On Mar 2, 2018, at 3:01 PM, Dave Fisher  wrote:
> 
> Hi -
> 
> I declared Lazy Consensus on Board@ for POI to take the XMLBeans product. So 
> far we have two positive responses.
> 
> Do we have LAZY CONSENSUS?
> 
> FYI - I did a full search of lists.apache.org  for 
> mentions of XMLBeans through sometime in August 2017
> 
> Here are the projects:
> 
> XMLBeans
> ———
> ODE
> NetBeans
> Axis
> Camel
> UIMA
> CXF
> Struts (2.3)
> Nifi
> Axis
> ManifoldCF
> Nutch
> Maven(?)
> WS
> OpenMeetings
> Buildr
> Synapse
> OpenWebBeans
> ServiceMix
> JUDDI (2.4)
> Flink
> Sling (2.3)
> 
> POI
> ——
> Nifi
> Solr
> Zika
> ManifoldCF
> ServiceMix
> 
> I think we should continue to build and release a new version of XMLBeans 
> 2.7.0
> 
> When we do so we update the website.
> 
> Meanwhile it would be fair to let all of these PMCs know our plan and why 
> this is needed. They can then help if they would like.
> 
> BTW - The XMLBeans project used JIRA ….
> 
> Regards,
> Dave
> 
>> On Mar 2, 2018, at 11:50 AM, Mark Murphy > > wrote:
>> 
>> That will make things a lot easier. Thanks Dave.
>> 
>> On Fri, Mar 2, 2018 at 2:45 PM, Dave Fisher > > wrote:
>> 
>>> Hi -
>>> 
>>> Given the Attic position and the mention of Royale. I will just take this
>>> to the Board.
>>> 
>>> They could take a resolution moving directly to POI. I will ask for this
>>> first.
>>> 
>>> Regards,
>>> Dave
>>> 
 On Mar 2, 2018, at 11:35 AM, Dave Fisher > wrote:
 
 Hi -
 
 As both an IPMC member and as a POI PMC member I would prefer that we
>>> direct to POI.
 
 I think we (POI) need to take over the XMLBeans Product.
 
 Regards,
 Dave
 
> On Mar 2, 2018, at 11:32 AM, Mark Murphy  > wrote:
> 
> So Oracle is removing JAXB from Java SE, Depricated in v9, to be
>>> removed in
> v11. I think we are stuck with XMLBeans for a while anyway. POI can
>>> sponsor
> XMLBeans which can then be put into incubation. At that point we can
>>> make
> updates. At some point XMLBeans emerges from incubation to be either a
> sub-project of POI, or it's own TLP. That need not be a big issue. We
>>> just
> need to keep it from being terminated. It isn't bad to be in Incubation.
> NetBeans is in Incubation. It will just stay there until we figure out
>>> how
> to manage it. If we take it over, we already have a community. The
> important part is to get it to a point where we can make updates to it.
>>> I
> think just making a fork for us, and giving it a new namespace could
>>> cause
> problems down the road with other projects that use POI and XMLBeans.
> 
> On Fri, Mar 2, 2018 at 9:45 AM, pj.fanning  > wrote:
> 
>> http://mail-archives.apache.org/mod_mbox/attic-general/ 
>> 
>>> 201803.mbox/browser
>> 
>> I think we could spend a lot of time on the attic approach.
>> 
>> 
>> 
>> 
>> --
>> Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866 
>> .
>>> html
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org 
>> 
>> For additional commands, e-mail: dev-h...@poi.apache.org 
>> 
>> 
>> 
 
>>> 
>>> 
> 



signature.asc
Description: Message signed with OpenPGP

Jenkins build is back to normal : POI-DSL-1.8 #377

[Apache Jenkins Server]

See 



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

Jenkins build is back to normal : POI-DSL-OpenJDK #381

[Apache Jenkins Server]

See 



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

Jenkins build is back to normal : POI-DSL-Windows-1.8 #148

[Apache Jenkins Server]

See 



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