I'm having trouble with getting spnego to work, and was hoping someone might
help.
I'm trying to perform a "Negotiate" authentication from a browser. My browser
is Chrome on Windows 10.
The endpoint I'm connecting to us a standard jetty server (it's wrapped up in
karaf), but I've implemented the
> 1.3.6.1.4.1.311.2.2.10 is NTLM which has a much smaller token size. Java
> does not support NTLM as a GSS-API mechanism.
Yes. So it looks like the browser is preferring NTLM and pre-emptively sending
a token for that.
> I am not sure how this happens. Normally you need to configure th
, but you might be interested in the JavaOne 2007
presentation "Leveraging Solaris Trusted Extensions to Implement
Platform Security Services for the Java Language".
http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-1427&yr=2007&track=5
Tom Hawtin
can't give guarantees about serialisation, that doesn't mean
that it doesn't. We probably don't want to upset anything relying upon
it. Having said that, in this case it doesn't seem to be reasonably
accessible. Shame there isn't a good way of marking a class
non-serialisable.
Tom
ermission does not correctly specify behaviour of wildcards
(should probably have a CR)
Tom
l non-empty name,
including those with a trailing dot. If I had to invent a meaning of the
trailing dot, I'd say it was superfluous, which matches the code.
As usual with ad hoc text formats the have parsing spread around the
code and no clear specification, they're a bit of a mess.
Tom
privileged action object
Tom
On 23/07/2014 14:40, David M. Lloyd wrote:
On 07/23/2014 07:07 AM, Tom Hawtin wrote:
On 23/07/2014 05:26, David M. Lloyd wrote:
• Always have static initialization blocks be privileged (this does
require users to be cognizant of this fact when writing static blocks)
If we were following
the
previously null URL.hostAddress, and locking based on the value of
URL.getHost (don't synchronise on String (that'd be a little like
synchronising on URL!)!). There's probably several places in the Java
library doing something similar with Maps and Futures.
Tom
e. So switching from an effectively global lock to a
lock based on hostname value is unlikely to help performance.
Tom
nt to start adding to those lists of methods.
Retrospectively relaxing access checking on existing methods would
potentially open flaws.
A sensible fix is to stop JTable exploiting the vulnerability. There are
a variety of ways of doing so.
Tom
[1]http://java.sun.com/security/seccodeguide.html
ere's _11:
Attr(#25) { // InnerClasses
[] { // InnerClasses
#4 #0 #0 8;
}
} // end InnerClasses
tom
On Aug 3, 2011, at 7:24 PM, Weijun Wang wrote:
>> serialVersionUID warnings for classes that have had different
>> generated serialVe
properties file may be specified
+# from the command line via the system property
+#
+#java.security.properties=
I think that should be:
+#-Djava.security.properties=
Tom
Looks good.
Tom
On 02/07/2012 16:54, Jason Uh wrote:
Thanks for your comments.
Please see updated webrev:
http://cr.openjdk.java.net/~juh/7133344/webrev.01
Jason
On 07/02/2012 08:45 AM, Tom Hawtin wrote:
On 02/07/2012 16:00, Jason Uh wrote:
This change is documentation for allowing a
-dimensional array of ints. This
step used to be done in the routine setSubKey.
-- Tom Deneau
Alan --
Can you tell me the procedure I should follow?
I have submitted hotspot webrevs before but not JDK webrevs?
-- Tom
-Original Message-
From: Alan Bateman [mailto:alan.bate...@oracle.com]
Sent: Tuesday, July 17, 2012 3:00 AM
To: Deneau, Tom
Cc: jdk7u-...@openjdk.java.net
Valerie, Max, Xuelei --
>From one who is not too familiar with the crypto architecture,
can you tell me under which provider scenario should we see
gains on 7107613 and 7107616?
-- Tom
-Original Message-
From: Valerie (Yu-Ching) Peng [mailto:valerie.p...@oracle.com]
Sent: Thurs
even with a fully trusted acc the permission check would
fail. Checking AllPermission in that case would make more sense.
Tom
that I'll have the output if it happens again.
I also have the logging and tracing enabled in the java control panel.
-- Tom
On Tue, Sep 19, 2017 at 12:13 PM, Sean Mullan
wrote:
> Cross-posting to security-dev as this is more relevant to that list and
> bcc-ing core-libs-dev.
>
iles"\Java\jre9b181\bin\javaws -J*-Djava.security.debug=all* %1
which also didn't work.
-- Tom
On Wed, Sep 20, 2017 at 12:56 PM, mandy chung
wrote:
> FYI. jdk.javaws is granted with AllPermissions in
> conf/security/javaws.policy. Maybe javaws.policy is not augmented to the
In case useful, our jnlp file also contains this:
On Wed, Sep 20, 2017 at 2:14 PM, Tom Hood wrote:
> Sean,
>
> I'll add those lines to the lib/security/default.policy file as you
> suggested. I left the app running overnight and came in this morning and
> it was s
nning with the JRE. I haven't tried running with the JDK
installation.
-- Tom
On Wed, Sep 20, 2017 at 2:17 PM, Tom Hood wrote:
> In case useful, our jnlp file also contains this:
>
>
>
>
>
> On Wed, Sep 20, 2017 at 2:14 PM, Tom Hood wrote:
>
>> Sean,
>&g
I have the source code for sun.* that matches
up with 8u172, otherwise I would try to find where else that property is
read. Even if I could get the reflection to work, it seems all too fragile
and likely to break in future Java updates. I'd prefer a different
approach.
Any suggestions?
Thank you,
-- Tom
g java.security properties, you use one
> equals, “=“. To override you use 2, “==‘. So you may want something like:
>
> java-vm-args="-Djava.security.properties==override_file"
>
>
> Tony
>
> On May 21, 2018, at 7:48 PM, Tom Hood wrote:
>
> Hi,
>
> Our
e the problem that you do not get javaws updates starting on
> January (easily) anymore.
>
> JNLP does not allow to overwrite random properties for the started app.
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> --
> *From:* security-
25 matches
Mail list logo
