[jdk17] Withdrawn: 8271489: (doc) Clarify Filter Factory example
On Thu, 29 Jul 2021 16:36:21 GMT, Roger Riggs wrote: > Improve the clarity of comments in the ObjectInputFilter FilterInThread > example. This pull request has been closed without being integrated. - PR: https://git.openjdk.java.net/jdk17/pull/292
Re: RFR: 8232066: Remove outdated code/methods from PKIX implementation [v2]
> Please review this fix to remove the Validator.VAR_PLUGIN_CODE_SIGNING > variant and related code that is no longer needed in the PKIX implementation. Sean Mullan has updated the pull request incrementally with one additional commit since the last revision: Remove NPE check in Validator.getInstance. Update ConstructorTest not to test for this case anymore. - Changes: - all: https://git.openjdk.java.net/jdk/pull/4934/files - new: https://git.openjdk.java.net/jdk/pull/4934/files/52be3dd2..b388bb4b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=4934=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=4934=00-01 Stats: 26 lines in 2 files changed: 0 ins; 21 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/4934.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4934/head:pull/4934 PR: https://git.openjdk.java.net/jdk/pull/4934
Re: RFR: 8232066: Remove outdated code/methods from PKIX implementation [v2]
On Thu, 29 Jul 2021 15:09:14 GMT, Weijun Wang wrote: > Looks good. One nit: `Validator::getInstance` methods are internal. Does it > really matter to check for null? Good point. Also, NPE will be thrown later when an `EndEntityChecker` is invoked and it needs to determine the variant to use. However, I had to change the `ConstructorTest` test not to test for this case anymore. - PR: https://git.openjdk.java.net/jdk/pull/4934
[jdk17] RFR: 8271489: (doc) Clarify Filter Factory example
Improve the clarity of comments in the ObjectInputFilter FilterInThread example. - Commit messages: - 8271489: (doc) Clarify Filter Factory example - 8270398: Enhance canonicalization - 8270404: Better canonicalization - Merge - Merge - 8263531: Remove unused buffer int - 8262731: [macOS] Exception from "Printable.print" is swallowed during "PrinterJob.print" - 8269763: The JEditorPane is blank after JDK-8265167 - 8265580: Enhanced style for RTF kit - 8265574: Improve handling of sheets - ... and 15 more: https://git.openjdk.java.net/jdk17/compare/c1304519...650e1561 Changes: https://git.openjdk.java.net/jdk17/pull/292/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17=292=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271489 Stats: 1001 lines in 42 files changed: 625 ins; 181 del; 195 mod Patch: https://git.openjdk.java.net/jdk17/pull/292.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/292/head:pull/292 PR: https://git.openjdk.java.net/jdk17/pull/292
Re: RFR: 8232066: Remove outdated code/methods from PKIX implementation
On Thu, 29 Jul 2021 14:24:52 GMT, Sean Mullan wrote: > Please review this fix to remove the Validator.VAR_PLUGIN_CODE_SIGNING > variant and related code that is no longer needed in the PKIX implementation. Looks good. One nit: `Validator::getInstance` methods are internal. Does it really matter to check for null? - Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4934
RFR: 8232066: Remove outdated code/methods from PKIX implementation
Please review this fix to remove the Validator.VAR_PLUGIN_CODE_SIGNING variant and related code that is no longer needed in the PKIX implementation. - Commit messages: - 8232066: Remove outdated code/methods from PKIX implementation Changes: https://git.openjdk.java.net/jdk/pull/4934/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4934=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8232066 Stats: 182 lines in 7 files changed: 6 ins; 167 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/4934.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4934/head:pull/4934 PR: https://git.openjdk.java.net/jdk/pull/4934
Re: Incorrect encoding of PKCS12 bag attributes
Are you calling the PKCS12Attribute(String, String) constructor from
your code? That API currently specifies that String values are encoded
as UTF-8, so we could not change the behavior without a specification
change. Can you use the PKCS12Attribute(byte[]) constructor instead
which takes a DER-encoded value?
--Sean
On 6/14/21 3:21 PM, Osipov, Michael (LDA IT PLM) wrote:
Folks,
can someone confirm the following bug or tell me I am too stupid to read
the RFCs:
I have recently created a PKCS12-based trust store and had one CA from
Hungary with non-ASCII chars in the subject's CN RDN.
RFC 7292 for friendlyName refers to RFC 2985, section 5.5.1:
friendlyName ATTRIBUTE ::= {
WITH SYNTAX BMPString (SIZE(1..pkcs-9-ub-friendlyName))
EQUALITY MATCHING RULE caseIgnoreMatch
SINGLE VALUE TRUE
ID pkcs-9-at-friendlyName
}
So a BMPString -- which is UCS-2 encoding. Looking at [1] shows that
Java ignores the RFC and always creates an UTF8String regardless of the
attribute OID, thus breaking the semantics of friendlyName.
Who's wrong here?
For some strange reason OpenSSL does it in a similar fashion:
In pkcs12.h.in:
> # define PKCS12_add_friendlyname PKCS12_add_friendlyname_utf8
where the function contains:
if (X509at_add1_attr_by_NID(>attrib, NID_friendlyName,
MBSTRING_UTF8, (unsigned char *)name, namelen)
!= NULL)
[1]
https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.base/share/classes/java/security/PKCS12Attribute.java#L230-L245
Regards,
Michael
Re: How to remove the SecurityManager
Appended inline below.
On 29/07/2021 11:20 am, Peter Firmstone wrote:
The intent of the following process is to perform a targeted audit,
which allows inspection of small parts of the code identified by these
steps.
On 28/07/2021 9:12 am, Peter Firmstone wrote:
Our process for establishing whether third party libraries are
trusted before we use them:
1. Build dependency check using Owasp
https://owasp.org/www-project-dependency-check/ Reject any
dependencies that fail, see
https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/pom.xml line
87 for an example of a disabled module due to a vulnerability in
a dependency, the module will only be re-enabled if the
vulnerability is fixed.
2. Static analysis using SpotBugs, then review identified bugs,
review source code if available. Reject if security bugs are
present, or fix / patch.
3. Profiling of permission access checks using:
https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/tools/security-policy-debug/src/main/java/org/apache/river/tool/SecurityPolicyWriter.java
4. Reviewing generated policy files, using grep, this example was
generated from over 2000 tests:
https://github.com/pfirmstone/JGDMS/blob/trunk/qa/harness/policy/defaultsecuresharedvm.policy.new
5. Remove any permission from the policy file you don't want to
grant to third party code, if safe to do so, eg usage statistics
reporting.
In the construction industry, a similar approach is used by structural
engineers and weld inspectors, when inspecting welds for defects,
using Ultrasonic, X-Ray or visual inspection, weld defects in
structures have the potential to cause catastrophic failure and
multiple fatalities, likely worse consequences than a bug in Java, so
engineers identify critical areas for inspectors to target with 100%
coverage, perhaps by UT or X-Ray, to inspect the weld internally, then
the structural engineer will nominate to inspect 10% of other areas
with UT, with 100% visual inspection, for example, if defects are
found, then they will increase UT inspection coverage, welds need to
be gouged out and re-welded, until the inspector is satisfied with
quality.
A targeted code audit process will also identify code quality, if
there are many bugs, don't use it, even if these aren't security bugs.
This can hardly be compared with the approach used for running Applets
in a sandbox that may have malicious intent, in that case no auditing
has been performed at all.
This use case of SecurityManager recognizes shortcomings of Java
platform security. Sandboxing was a marketing term used for Applets,
I don't know the origin of the term sandbox when used for computer
security, but whenever there is a sandbox, there is a risk of escape,
and simplicity is thy friend, it should be left to cyber security
professionals.
If you removed applets, then there is no use case for a Sandbox, so
why remove SecurityManager?
Come on honestly, JEP 411 is confirmation biased, is overly focused on
sandboxing and therefore not factual or relevant, I've provided
sufficient evidence contrary to it's claims. It needs to take the
ability to migrate code into account as well as use cases other than
sandboxing.
We use SM to prevent loading of untrusted (unaudited) code and
untrusted (unauthenticated) data, but we don't use it as a sandbox to
attempt to encapsulate malicious code and malicious users, we use it
for authorization decisions, for external users and services, this
could also be applied to Web Services, not just Jini services, these
authorization decisions prevent loading untrusted code and parsing
untrusted data.
grant codebase
"httpmd://${HOST}:9080/${mercury-dl.jar};sha-384=041531e5e3de288c121e865af8a46f7af86172ee0127dc4aff4f551c73a0ad604f51cb1c53076140fd415f957c14e8dd",
principal javax.security.auth.x500.X500Principal "CN=Outrigger"
{
permission org.apache.river.api.io.DeSerializationPermission
"MARSHALL";
permission net.jini.security.AuthenticationPermission
"javax.security.auth.x500.X500Principal \"CN=Outrigger\" peer
javax.security.auth.x500.X500Principal \"CN=Phoenix\"", "connect";
};
Rather than throwing developers who use SM under the bus, we could be
given a migration path:
1. Review and reduce the number of permissions focused *only* on
authorization use cases. Eg: Give Properties useful for
authorization their own guarded area in the Property map? I
mean, why are we guarding java.util.PropertyPermission
"java.specification.version", "read" and many others like it?
Fix SocketPermission, add netmask wild cards, use RFC3986
normalization, stop using DNS. Ever heard of DNS spoofing?
2. What about parsing of data? Such as XML and Java Serialization,
among others, this should have a permission check, that when
granted to users, ensures the data source has been
authenticated. This is a server application, not
