Re: [VOTE] Apache LDAP API 2.1.2
+1 * Built from source * Verified checksums and signatures * Tested in Studio On 8/10/22 08:44, Emmanuel Lécharny wrote: Hi all, this is a vote for the release of Apache LDAP API 2.1.2 This is a correction in the package construction, in order to be bale to run Apache Directory Server with Java 8 (with the 2.1.1 version, Java 11 was required). There is no other significative change. The revision : https://gitbox.apache.org/repos/asf?p=directory-ldap-api.git;a=commit;h=b6a137dcfdc0495776cf7f5904556d88dcc14880 The source and binary distribution packages: https://dist.apache.org/repos/dist/dev/directory/api/2.1.2 The staging repository: https://repository.apache.org/content/repositories/orgapachedirectory-1210 Please cast your votes: [ ] +1 Release Apache LDAP API 2.1.2 [ ] 0 abstain [ ] -1 Do not release Apache LDAP API 2.1.2 Thanks ! - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
Re: [VOTE] Apache LDAP API 2.1.1
+ 1 * Built from source * Verified checksums and signatures * Tested in Studio, tests pass (only the ApacheDS used in integration tests which is stated via new ApacheDirectoryServer().start() doesn't work with the updated Mina version, but that's expected and will be fixed with the next ApacheDS release I assume) Thanks Emmanuel! On 7/29/22 06:54, Emmanuel Lécharny wrote: Hi all, this is a vote for the release of Apache LDAP API 2.1.1 This is a bug fix release. It also contains a switch to MINA 2.2.1, which includes a complete rewrite of the TLS layer The revision : https://gitbox.apache.org/repos/asf?p=directory-ldap-api.git;a=commit;h=df7b3b60779c74e9494a18773a449f201b98f776 The source and binary distribution packages: https://dist.apache.org/repos/dist/dev/directory/api/2.1.1 The staging repository: https://repository.apache.org/content/repositories/orgapachedirectory-1209 Please cast your votes: [ ] +1 Release Apache LDAP API 2.1.1 [ ] 0 abstain [ ] -1 Do not release Apache LDAP API 2.1.1 Thanks ! - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Resolved] (DIRSTUDIO-1300) Use LookupTranslator instead of chained replace() calls
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seelmann resolved DIRSTUDIO-1300.
Resolution: Fixed
> Use LookupTranslator instead of chained replace() calls
> ---
>
> Key: DIRSTUDIO-1300
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1300
> Project: Directory Studio
> Issue Type: Improvement
> Components: studio-ldapbrowser
>Affects Versions: 2.0.0-M17
>Reporter: Fredrik Roubert
>Priority: Minor
> Fix For: 2.0.0-M18
>
>
> Using chained calls to {{String.replace()}} is simple but suboptimal, it'd be
> better to use the
> [LookupTranslator|https://commons.apache.org/proper/commons-text/javadocs/api-release/org/apache/commons/text/translate/LookupTranslator.html]
> from the commons-text library instead.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Resolved] (DIRSTUDIO-933) Order search value history by creation date instead of alphabetically
[ https://issues.apache.org/jira/browse/DIRSTUDIO-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann resolved DIRSTUDIO-933. --- Resolution: Fixed > Order search value history by creation date instead of alphabetically > - > > Key: DIRSTUDIO-933 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-933 > Project: Directory Studio > Issue Type: Bug > Components: studio-ldapbrowser >Affects Versions: 2.0.0-M17 >Reporter: Nabil Sayegh >Assignee: Lothar Haeger >Priority: Trivial > Labels: dropdownlist, history, search > Fix For: 2.0.0-M18 > > > The search value history shouldn't be sorted alphabetically but rather > historically, either by creation date or last use date -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Resolved] (DIRSTUDIO-1298) The RFC 4517 Postal Address value editor en-/decoding is incomplete
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann resolved DIRSTUDIO-1298. Resolution: Fixed Thanks [~roubert] for the PR > The RFC 4517 Postal Address value editor en-/decoding is incomplete > --- > > Key: DIRSTUDIO-1298 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1298 > Project: Directory Studio > Issue Type: Bug > Components: studio-ldapbrowser >Affects Versions: 2.0.0-M17 >Reporter: Fredrik Roubert >Priority: Major > Fix For: 2.0.0-M18 > > > The current implementation only handles newlines but not the other two > (dollar sign and backslash) character for which RFC 4517 specifies an > encoding, meaning that it can't handle addresses containing these characters. > These characters are rare in real life postal addresses (even though the RFC > contains a somewhat convincing example address) and this is probably the > reason for why no-one else has cared until now, but it would still be better > to implement the standard correctly than incompletely. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Updated] (DIRSTUDIO-1298) The RFC 4517 Postal Address value editor en-/decoding is incomplete
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann updated DIRSTUDIO-1298: --- Fix Version/s: 2.0.0-M18 > The RFC 4517 Postal Address value editor en-/decoding is incomplete > --- > > Key: DIRSTUDIO-1298 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1298 > Project: Directory Studio > Issue Type: Bug > Components: studio-ldapbrowser >Affects Versions: 2.0.0-M17 >Reporter: Fredrik Roubert >Priority: Major > Fix For: 2.0.0-M18 > > > The current implementation only handles newlines but not the other two > (dollar sign and backslash) character for which RFC 4517 specifies an > encoding, meaning that it can't handle addresses containing these characters. > These characters are rare in real life postal addresses (even though the RFC > contains a somewhat convincing example address) and this is probably the > reason for why no-one else has cared until now, but it would still be better > to implement the standard correctly than incompletely. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Resolved] (DIRSTUDIO-1296) Export doesn't decode RFC 4517 Postal Address syntax
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seelmann resolved DIRSTUDIO-1296.
Resolution: Fixed
Thanks again Frederik for the proposal and the PR, and apologies for the very
late response.
> Export doesn't decode RFC 4517 Postal Address syntax
>
>
> Key: DIRSTUDIO-1296
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1296
> Project: Directory Studio
> Issue Type: Bug
> Components: studio-ldapbrowser
>Affects Versions: 2.0.0-M17
>Reporter: Fredrik Roubert
>Priority: Major
> Fix For: 2.0.0-M18
>
>
> When exporting any entries using the RFC 4517 Postal Address syntax
> (1.3.6.1.4.1.1466.115.121.1.41) to any non-LDAP data format (CSV, Excel, …)
> these entries aren't decoded but the RFC 4517 escaped data is instead
> exported as-is, like this:
> \241,000,000 Sweepstakes$PO Box 100$Anytown, CA 12345$USA
> … instead of this:
> $1,000,000 Sweepstakes
> {{PO Box 100}}
> {{Anytown, CA 12345}}
> {{USA}}
> I think it's safe to assume that no non-LDAP software is expected to be able
> to decode RFC 4517 escaped data, so not doing this decoding upon export must
> be a bug.
> (This data is correctly decoded and encoded by default for display and edit
> within Directory Studio itself.)
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Updated] (DIRSTUDIO-1295) When closing connection to LDAP, connection doesn't UNBIND and resulting in a lost connection from server
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seelmann updated DIRSTUDIO-1295:
---
Fix Version/s: 2.0.0-M18
> When closing connection to LDAP, connection doesn't UNBIND and resulting in a
> lost connection from server
> -
>
> Key: DIRSTUDIO-1295
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1295
> Project: Directory Studio
> Issue Type: Bug
> Components: studio-connection
>Affects Versions: 2.0.0-M17
> Environment: N/A
>Reporter: Manuel FLURY
>Priority: Minor
> Fix For: 2.0.0-M18
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> When opening a connection to LDAP server with credentials, connection is
> opened, but when pushing the "close connection" using contextual menu, it
> doesn't UNBIND before triggering a connection lost error
>
> {{Feb 14 16:41:43 myLDAPserver slapd[1946001]: conn=1000 fd=13 ACCEPT from
> IP=10.153.200.152:58180 (IP=0.0.0.0:11389)}}
> {{Feb 14 16:41:43 myLDAPserver slapd[1946001]: conn=1000 op=0 BIND
> dn="cn=Directory Manager,dc=example,dc=com" method=128}}
> {{Feb 14 16:41:43 myLDAPserver slapd[1946001]: conn=1000 op=0 BIND
> dn="cn=Directory Manager,dc=example,dc=com" mech=SIMPLE bind_ssf=0 ssf=0}}
> {{Feb 14 16:41:43 myLDAPserver slapd[1946001]: conn=1000 op=0 RESULT tag=97
> err=0 qtime=0.14 etime=0.000105 text=}}
> {{{}.../...{}}}{{{}Feb 14 17:37:17 myLDAPserver slapd[1946001]: conn=1000
> op=29 SEARCH RESULT tag=101 err=0 qtime=0.18 etime=0.000108 nentries=1
> text={}}}
> {{{color:#de350b}Feb 14 17:37:27 myLDAPserver slapd[1946001]: conn=1000 fd=13
> closed (connection lost){color}}}
> {{}}
> I think there should be an UNBIND before closing connection.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Updated] (DIRSTUDIO-953) LDAP Browser - Quick Search Entry fields for attr and value do not support copy/paste by keystroke on Win7
[ https://issues.apache.org/jira/browse/DIRSTUDIO-953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann updated DIRSTUDIO-953: -- Fix Version/s: 2.0.0-M18 > LDAP Browser - Quick Search Entry fields for attr and value do not support > copy/paste by keystroke on Win7 > -- > > Key: DIRSTUDIO-953 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-953 > Project: Directory Studio > Issue Type: Bug >Affects Versions: 2.0.0-M8 (2.0.0.v20130628) > Environment: Win7-64, Linux >Reporter: Lothar Haeger >Priority: Major > Fix For: 2.0.0-M18 > > > CTRL-C and CTRL-V do not work in quick search entry fields for attr names and > values -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Updated] (DIRSTUDIO-826) Impossible to paste into Quick Search fields
[ https://issues.apache.org/jira/browse/DIRSTUDIO-826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann updated DIRSTUDIO-826: -- Fix Version/s: 2.0.0-M18 > Impossible to paste into Quick Search fields > > > Key: DIRSTUDIO-826 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-826 > Project: Directory Studio > Issue Type: Bug >Affects Versions: 1.5.3, 2.0.0-M1 (2.0.0.v20120111), 2.0.0-M2 > (2.0.0.v20120127), 2.0.0-M3 (2.0.0.v20120224) > Environment: OS X Lion > OS X Mountain Lion >Reporter: Nabil Sayegh >Assignee: Pierre-Arnaud Marcelot >Priority: Major > Labels: clipboard, paste, quicksearch > Fix For: 2.0.0-M18 > > > Paste into quicksearch fields doesn't work on OS X (Lion/Mountain Lion) -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Updated] (DIRSTUDIO-1284) Error while executing LDIF - [LDAP result code 53 - unwillingToPerform] - Must supply correct old password to change to new one
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seelmann updated DIRSTUDIO-1284:
---
Fix Version/s: (was: 2.0.0-M15)
> Error while executing LDIF - [LDAP result code 53 - unwillingToPerform] -
> Must supply correct old password to change to new one
> ---
>
> Key: DIRSTUDIO-1284
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1284
> Project: Directory Studio
> Issue Type: Bug
> Components: studio-ldifeditor
>Affects Versions: 2.0.0-M17
> Environment: Mac OS 11.4, running on a MacBook Pro (16-inch, 2019)
>Reporter: Katie Golan
>Priority: Major
> Fix For: 2.0.0-M18
>
> Attachments: Screen Shot 2021-07-06 at 9.22.13 AM.jpg, Screen Shot
> 2021-07-28 at 3.36.39 PM.png, screenshot-1.png
>
>
> The current version of Apache Directory Studio (2.0.0.v20210717-M17) seems to
> have a bug with password resets. I’ve confirmed that version
> {{2.0.0.v20200411-M15}} does not have this bug.
> # In Password Editor, the same password is entered for "Enter New Password"
> and "Confirm New Password"
> # When you click "OK", the following error results:
> "Error while executing LDIF
> - [LDAP result code 53 - unwillingToPerform] Must supply correct old
> password to change to new one"
>
> * I successfully reset the password for User A on version M15.
> * After upgrading to version M17, I got the above error when attempting a
> password reset for User A.
> * I then uninstalled Apache, rebooted, and reinstalled version M15.
> * After M15 reinstall, I was able to successfully reset User A's password
> again.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Updated] (DIRSTUDIO-1284) Error while executing LDIF - [LDAP result code 53 - unwillingToPerform] - Must supply correct old password to change to new one
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seelmann updated DIRSTUDIO-1284:
---
Fix Version/s: 2.0.0-M18
> Error while executing LDIF - [LDAP result code 53 - unwillingToPerform] -
> Must supply correct old password to change to new one
> ---
>
> Key: DIRSTUDIO-1284
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1284
> Project: Directory Studio
> Issue Type: Bug
> Components: studio-ldifeditor
>Affects Versions: 2.0.0-M17
> Environment: Mac OS 11.4, running on a MacBook Pro (16-inch, 2019)
>Reporter: Katie Golan
>Priority: Major
> Fix For: 2.0.0-M15, 2.0.0-M18
>
> Attachments: Screen Shot 2021-07-06 at 9.22.13 AM.jpg, Screen Shot
> 2021-07-28 at 3.36.39 PM.png, screenshot-1.png
>
>
> The current version of Apache Directory Studio (2.0.0.v20210717-M17) seems to
> have a bug with password resets. I’ve confirmed that version
> {{2.0.0.v20200411-M15}} does not have this bug.
> # In Password Editor, the same password is entered for "Enter New Password"
> and "Confirm New Password"
> # When you click "OK", the following error results:
> "Error while executing LDIF
> - [LDAP result code 53 - unwillingToPerform] Must supply correct old
> password to change to new one"
>
> * I successfully reset the password for User A on version M15.
> * After upgrading to version M17, I got the above error when attempting a
> password reset for User A.
> * I then uninstalled Apache, rebooted, and reinstalled version M15.
> * After M15 reinstall, I was able to successfully reset User A's password
> again.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Updated] (DIRSTUDIO-1289) Can't connect to ldaps behind haproxy in M17
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seelmann updated DIRSTUDIO-1289:
---
Fix Version/s: 2.0.0-M18
> Can't connect to ldaps behind haproxy in M17
>
>
> Key: DIRSTUDIO-1289
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1289
> Project: Directory Studio
> Issue Type: Bug
> Components: studio-ldapbrowser
>Affects Versions: 2.0.0-M17
> Environment: OS: Linux, v.5.13.13-arch1-1, x86_64 / gtk 3.24.30
> Java version: 16.0.2
>Reporter: Josef Vybíhal
>Priority: Minor
> Labels: LDAPS, haproxy
> Fix For: 2.0.0-M16, 2.0.0-M18
>
>
> I have noticed, that I can not connect to ldaps server which is behind SSL
> terminated haproxy.
> The error seems to be timeout
> {code:java}
> Error while opening connectionError while opening connection -
> ERR_04169_RESPONSE_QUEUE_EMPTIED The response queue has been emptied, no
> response was
> found.org.apache.directory.studio.connection.core.io.StudioLdapException:
> ERR_04169_RESPONSE_QUEUE_EMPTIED The response queue has been emptied, no
> response was found. at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.toStudioLdapException(DirectoryApiConnectionWrapper.java:1350)
> at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.access$2(DirectoryApiConnectionWrapper.java:1342)
> at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper$2.run(DirectoryApiConnectionWrapper.java:483)
> at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.runAndMonitor(DirectoryApiConnectionWrapper.java:1261)
> at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.doBind(DirectoryApiConnectionWrapper.java:488)
> at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.bind(DirectoryApiConnectionWrapper.java:323)
> at
> org.apache.directory.studio.connection.core.jobs.OpenConnectionsRunnable.run(OpenConnectionsRunnable.java:114)
> at
> org.apache.directory.studio.connection.core.jobs.StudioConnectionJob.run(StudioConnectionJob.java:109)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)Caused by:
> org.apache.directory.api.ldap.model.exception.LdapException:
> ERR_04169_RESPONSE_QUEUE_EMPTIED The response queue has been emptied, no
> response was found. at
> org.apache.directory.ldap.client.api.LdapNetworkConnection.bind(LdapNetworkConnection.java:1578)
> at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.bindSimple(DirectoryApiConnectionWrapper.java:339)
> at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.access$5(DirectoryApiConnectionWrapper.java:333)
> at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper$2.run(DirectoryApiConnectionWrapper.java:395)
> ... 6 moreCaused by:
> org.apache.directory.api.ldap.model.exception.LdapException:
> ERR_04170_TIMEOUT_OCCURED TimeOut occurred at
> org.apache.directory.ldap.client.api.LdapNetworkConnection.bind(LdapNetworkConnection.java:1549)
> ... 9 more
> ERR_04169_RESPONSE_QUEUE_EMPTIED The response queue has been emptied, no
> response was found.{code}
> In the haproxy log, I can see the connection was made. The ldap servers in
> the backed are definitely responding properly (I can connect to them
> directly, and numerous applications are using this haproxy as ldap source,
> and it works perfectly fine).
> I suspect it is something in M17.
> When I downgraded to 2.0.0.v20210213-M16, it works fine - I can connect as
> expected. I have tried M17 with java-16-jdk and java-11-openjdk, no change.
> Is there anything I could investigate more and help discovering what the
> issue might be?
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Updated] (DIRSTUDIO-1287) Error connecting to LDAPS server
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seelmann updated DIRSTUDIO-1287:
---
Fix Version/s: 2.0.0-M18
> Error connecting to LDAPS server
>
>
> Key: DIRSTUDIO-1287
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1287
> Project: Directory Studio
> Issue Type: Bug
>Affects Versions: 2.0.0-M17
>Reporter: Robin
>Priority: Major
> Fix For: 2.0.0-M18
>
>
> In trying to connect to an LDAP server via TLS I have run into what I believe
> to be a bug.
> The LDAP server is the built-in one on a Synology NAS with a valid
> certificate installed.
> I am able to successfully bind to it using LDAPS on port 636 using
> javax.naming:
> {code:java}
> Hashtable env = new Hashtable();
> env.put(Context.INITIAL_CONTEXT_FACTORY,
> "com.sun.jndi.ldap.LdapCtxFactory");
> env.put(Context.PROVIDER_URL, ldapUrl);
> env.put(Context.SECURITY_AUTHENTICATION, authentication);
> env.put(Context.SECURITY_PRINCIPAL, bindDN);
> env.put(Context.SECURITY_CREDENTIALS, password);
> return new InitialLdapContext (env, null);
> {code}
> However, when trying to connect using Apache Directory Studio I keep getting
> an error:
> The authentication failed ERR_04169_RESPONSE_QUEUE_EMPTIED The response queue
> has been emptied, no response was found.
> I started Directory Studio with -Djavax.net.debug=all to see what happens and
> this is what I found:
> * There's a bunch of logging which eventually ends with this line:
> {code:java}
> javax.net.ssl|ALL|34|NioProcessor-5|2021-08-19 09:52:20.548
> BST|SSLSessionImpl.java:242|Session initialized:
> Session(1629363140485|TLS_AES_128_GCM_SHA256){code}
> * It then idles for a while after which this happens:
> {code:java}
> javax.net.ssl|ALL|32|Worker-4: Open Connection|2021-08-19 09:52:50.512
> BST|SSLEngineImpl.java:752|Closing outbound of SSLEngine
> javax.net.ssl|WARNING|32|Worker-4: Open Connection|2021-08-19 09:52:50.512
> BST|SSLEngineOutputRecord.java:168|outbound has closed, ignore outbound
> application data
> javax.net.ssl|DEBUG|32|Worker-4: Open Connection|2021-08-19 09:52:50.512
> BST|SSLEngineOutputRecord.java:505|WRITE: TLS13 alert, length = 2
> javax.net.ssl|DEBUG|32|Worker-4: Open Connection|2021-08-19 09:52:50.512
> BST|SSLCipher.java:2036|Plaintext before ENCRYPTION (
> : 01 00 15 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0010: 00 00 00 ...
> )
> javax.net.ssl|DEBUG|32|Worker-4: Open Connection|2021-08-19 09:52:50.512
> BST|SSLEngineOutputRecord.java:523|Raw write (
> : 17 03 03 00 23 00 65 A2 9A C7 DD 2C 23 8D 18 75 #.e,#..u
> 0010: 98 7F 17 DD 3B 01 61 36 C8 83 9A E1 0D 41 B0 00 ;.a6.A..
> 0020: 07 8D 20 48 EB 1E 31 7B.. H..1.
> )
> javax.net.ssl|ALL|34|NioProcessor-5|2021-08-19 09:52:50.513
> BST|SSLEngineImpl.java:724|Closing inbound of SSLEngine
> javax.net.ssl|ERROR|34|NioProcessor-5|2021-08-19 09:52:50.514
> BST|TransportContext.java:341|Fatal (INTERNAL_ERROR): closing inbound before
> receiving peer's close_notify (
> "throwable" : {
> javax.net.ssl.SSLException: closing inbound before receiving peer's
> close_notify
> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:133)
> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
> at
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:336)
> at
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:292)
> at
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:283)
> at
> java.base/sun.security.ssl.SSLEngineImpl.closeInbound(SSLEngineImpl.java:733)
> at org.apache.mina.filter.ssl.SslHandler.destroy(SslHandler.java:209)
> at
> org.apache.mina.filter.ssl.SslFilter.sessionClosed(SslFilter.java:485)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextSessionClosed(DefaultIoFilterChain.java:606)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$900(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.sessionClosed(DefaultIoFilterChain.java:1092)
> at
> org.apache.mina.core.filterchain.IoFilterAdapter.sessionClosed(IoFilterAdapter.java:98)
> at
> org.apache.mina.cor
[jira] [Updated] (DIRSTUDIO-1293) Fails to start on MacOS Monterey
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seelmann updated DIRSTUDIO-1293:
---
Fix Version/s: 2.0.0-M18
> Fails to start on MacOS Monterey
>
>
> Key: DIRSTUDIO-1293
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1293
> Project: Directory Studio
> Issue Type: Bug
> Components: studio-ldapbrowser
>Affects Versions: 2.0.0-M17
> Environment: Model Name:MacBook Pro
> Model Identifier: MacBookPro18,2
> Chip: Apple M1 Max
> Total Number of Cores: 10 (8 performance and 2 efficiency)
> Memory: 32 GB
> System Firmware Version:7429.41.5
> OS Loader Version: 7429.41.5
>Reporter: Philip Peake
>Priority: Major
> Fix For: 2.0.0-M18
>
> Attachments: alert.png
>
>
> Launching Directory Studio fails with an error (see attached image),
> basically saying that the JNI_CreateJavaVM symbol is not found in
> libjvm.dylib.
> The symbol is actually there:
>
> {code:java}
> bin philip$ nm ../lib/server/libjvm.dylib | grep -i jni_create
> 004e3190 T _JNI_CreateJavaVM
> {code}
>
> Tried two different java versions:
> * zulu-11.jdk
> * zulu-17.jdk
> Tried adding the path to the java version explicitly in the Info.plist file:
>
> {code:java}
>
>
>
>
> -vm/Library/Java/JavaVirtualMachines/zulu-17.jdk/Contents/Home/bin/java
> -keyring
> ~/.eclipse_keyring
>
>
> {code}
>
> This appears to be a problem in Eclipse/Directory Studio.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Updated] (DIRSTUDIO-1296) Export doesn't decode RFC 4517 Postal Address syntax
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seelmann updated DIRSTUDIO-1296:
---
Fix Version/s: 2.0.0-M18
> Export doesn't decode RFC 4517 Postal Address syntax
>
>
> Key: DIRSTUDIO-1296
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1296
> Project: Directory Studio
> Issue Type: Bug
> Components: studio-ldapbrowser
>Affects Versions: 2.0.0-M17
>Reporter: Fredrik Roubert
>Priority: Major
> Fix For: 2.0.0-M18
>
>
> When exporting any entries using the RFC 4517 Postal Address syntax
> (1.3.6.1.4.1.1466.115.121.1.41) to any non-LDAP data format (CSV, Excel, …)
> these entries aren't decoded but the RFC 4517 escaped data is instead
> exported as-is, like this:
> \241,000,000 Sweepstakes$PO Box 100$Anytown, CA 12345$USA
> … instead of this:
> $1,000,000 Sweepstakes
> {{PO Box 100}}
> {{Anytown, CA 12345}}
> {{USA}}
> I think it's safe to assume that no non-LDAP software is expected to be able
> to decode RFC 4517 escaped data, so not doing this decoding upon export must
> be a bug.
> (This data is correctly decoded and encoded by default for display and edit
> within Directory Studio itself.)
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Updated] (DIRSTUDIO-933) Order search value history by creation date instead of alphabetically
[ https://issues.apache.org/jira/browse/DIRSTUDIO-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann updated DIRSTUDIO-933: -- Fix Version/s: 2.0.0-M18 > Order search value history by creation date instead of alphabetically > - > > Key: DIRSTUDIO-933 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-933 > Project: Directory Studio > Issue Type: Bug > Components: studio-ldapbrowser >Affects Versions: 2.0.0-M17 >Reporter: Nabil Sayegh >Assignee: Lothar Haeger >Priority: Trivial > Labels: dropdownlist, history, search > Fix For: 2.0.0-M18 > > > The search value history shouldn't be sorted alphabetically but rather > historically, either by creation date or last use date -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRSTUDIO-1296) Export doesn't decode RFC 4517 Postal Address syntax
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17537149#comment-17537149
]
Stefan Seelmann commented on DIRSTUDIO-1296:
Thanks for the proposal and the PR. Your proposal makes proper sense to me for
the export to CSV/Excel/ODF.
> Export doesn't decode RFC 4517 Postal Address syntax
>
>
> Key: DIRSTUDIO-1296
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1296
> Project: Directory Studio
> Issue Type: Bug
> Components: studio-ldapbrowser
>Affects Versions: 2.0.0-M17
>Reporter: Fredrik Roubert
>Priority: Major
>
> When exporting any entries using the RFC 4517 Postal Address syntax
> (1.3.6.1.4.1.1466.115.121.1.41) to any non-LDAP data format (CSV, Excel, …)
> these entries aren't decoded but the RFC 4517 escaped data is instead
> exported as-is, like this:
> \241,000,000 Sweepstakes$PO Box 100$Anytown, CA 12345$USA
> … instead of this:
> $1,000,000 Sweepstakes
> {{PO Box 100}}
> {{Anytown, CA 12345}}
> {{USA}}
> I think it's safe to assume that no non-LDAP software is expected to be able
> to decode RFC 4517 escaped data, so not doing this decoding upon export must
> be a bug.
> (This data is correctly decoded and encoded by default for display and edit
> within Directory Studio itself.)
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRSTUDIO-1287) Error connecting to LDAPS server
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17492582#comment-17492582
]
Stefan Seelmann commented on DIRSTUDIO-1287:
It's a know issue. Either we get a fixed Mina and API version soon, otherwise
we can remove the usage of TLSv1.3 from Studio (it's hard-coded).
https://issues.apache.org/jira/browse/DIRAPI-381
> Error connecting to LDAPS server
>
>
> Key: DIRSTUDIO-1287
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1287
> Project: Directory Studio
> Issue Type: Bug
>Affects Versions: 2.0.0-M17
>Reporter: Robin
>Priority: Major
>
> In trying to connect to an LDAP server via TLS I have run into what I believe
> to be a bug.
> The LDAP server is the built-in one on a Synology NAS with a valid
> certificate installed.
> I am able to successfully bind to it using LDAPS on port 636 using
> javax.naming:
> {code:java}
> Hashtable env = new Hashtable();
> env.put(Context.INITIAL_CONTEXT_FACTORY,
> "com.sun.jndi.ldap.LdapCtxFactory");
> env.put(Context.PROVIDER_URL, ldapUrl);
> env.put(Context.SECURITY_AUTHENTICATION, authentication);
> env.put(Context.SECURITY_PRINCIPAL, bindDN);
> env.put(Context.SECURITY_CREDENTIALS, password);
> return new InitialLdapContext (env, null);
> {code}
> However, when trying to connect using Apache Directory Studio I keep getting
> an error:
> The authentication failed ERR_04169_RESPONSE_QUEUE_EMPTIED The response queue
> has been emptied, no response was found.
> I started Directory Studio with -Djavax.net.debug=all to see what happens and
> this is what I found:
> * There's a bunch of logging which eventually ends with this line:
> {code:java}
> javax.net.ssl|ALL|34|NioProcessor-5|2021-08-19 09:52:20.548
> BST|SSLSessionImpl.java:242|Session initialized:
> Session(1629363140485|TLS_AES_128_GCM_SHA256){code}
> * It then idles for a while after which this happens:
> {code:java}
> javax.net.ssl|ALL|32|Worker-4: Open Connection|2021-08-19 09:52:50.512
> BST|SSLEngineImpl.java:752|Closing outbound of SSLEngine
> javax.net.ssl|WARNING|32|Worker-4: Open Connection|2021-08-19 09:52:50.512
> BST|SSLEngineOutputRecord.java:168|outbound has closed, ignore outbound
> application data
> javax.net.ssl|DEBUG|32|Worker-4: Open Connection|2021-08-19 09:52:50.512
> BST|SSLEngineOutputRecord.java:505|WRITE: TLS13 alert, length = 2
> javax.net.ssl|DEBUG|32|Worker-4: Open Connection|2021-08-19 09:52:50.512
> BST|SSLCipher.java:2036|Plaintext before ENCRYPTION (
> : 01 00 15 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0010: 00 00 00 ...
> )
> javax.net.ssl|DEBUG|32|Worker-4: Open Connection|2021-08-19 09:52:50.512
> BST|SSLEngineOutputRecord.java:523|Raw write (
> : 17 03 03 00 23 00 65 A2 9A C7 DD 2C 23 8D 18 75 #.e,#..u
> 0010: 98 7F 17 DD 3B 01 61 36 C8 83 9A E1 0D 41 B0 00 ;.a6.A..
> 0020: 07 8D 20 48 EB 1E 31 7B.. H..1.
> )
> javax.net.ssl|ALL|34|NioProcessor-5|2021-08-19 09:52:50.513
> BST|SSLEngineImpl.java:724|Closing inbound of SSLEngine
> javax.net.ssl|ERROR|34|NioProcessor-5|2021-08-19 09:52:50.514
> BST|TransportContext.java:341|Fatal (INTERNAL_ERROR): closing inbound before
> receiving peer's close_notify (
> "throwable" : {
> javax.net.ssl.SSLException: closing inbound before receiving peer's
> close_notify
> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:133)
> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
> at
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:336)
> at
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:292)
> at
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:283)
> at
> java.base/sun.security.ssl.SSLEngineImpl.closeInbound(SSLEngineImpl.java:733)
> at org.apache.mina.filter.ssl.SslHandler.destroy(SslHandler.java:209)
> at
> org.apache.mina.filter.ssl.SslFilter.sessionClosed(SslFilter.java:485)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextSessionClosed(DefaultIoFilterChain.java:606)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$900(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$Entr
[jira] [Commented] (DIRSTUDIO-1289) Can't connect to ldaps behind haproxy in M17
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17492581#comment-17492581
]
Stefan Seelmann commented on DIRSTUDIO-1289:
It's a know issue. Either we get a fixed Mina and API version soon, otherwise
we can remove the usage of TLSv1.3 from Studio (it's hard-coded).
https://issues.apache.org/jira/browse/DIRAPI-381
> Can't connect to ldaps behind haproxy in M17
>
>
> Key: DIRSTUDIO-1289
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1289
> Project: Directory Studio
> Issue Type: Bug
> Components: studio-ldapbrowser
>Affects Versions: 2.0.0-M17
> Environment: OS: Linux, v.5.13.13-arch1-1, x86_64 / gtk 3.24.30
> Java version: 16.0.2
>Reporter: Josef Vybíhal
>Priority: Minor
> Labels: LDAPS, haproxy
> Fix For: 2.0.0-M16
>
>
> I have noticed, that I can not connect to ldaps server which is behind SSL
> terminated haproxy.
> The error seems to be timeout
> {code:java}
> Error while opening connectionError while opening connection -
> ERR_04169_RESPONSE_QUEUE_EMPTIED The response queue has been emptied, no
> response was
> found.org.apache.directory.studio.connection.core.io.StudioLdapException:
> ERR_04169_RESPONSE_QUEUE_EMPTIED The response queue has been emptied, no
> response was found. at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.toStudioLdapException(DirectoryApiConnectionWrapper.java:1350)
> at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.access$2(DirectoryApiConnectionWrapper.java:1342)
> at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper$2.run(DirectoryApiConnectionWrapper.java:483)
> at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.runAndMonitor(DirectoryApiConnectionWrapper.java:1261)
> at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.doBind(DirectoryApiConnectionWrapper.java:488)
> at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.bind(DirectoryApiConnectionWrapper.java:323)
> at
> org.apache.directory.studio.connection.core.jobs.OpenConnectionsRunnable.run(OpenConnectionsRunnable.java:114)
> at
> org.apache.directory.studio.connection.core.jobs.StudioConnectionJob.run(StudioConnectionJob.java:109)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)Caused by:
> org.apache.directory.api.ldap.model.exception.LdapException:
> ERR_04169_RESPONSE_QUEUE_EMPTIED The response queue has been emptied, no
> response was found. at
> org.apache.directory.ldap.client.api.LdapNetworkConnection.bind(LdapNetworkConnection.java:1578)
> at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.bindSimple(DirectoryApiConnectionWrapper.java:339)
> at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.access$5(DirectoryApiConnectionWrapper.java:333)
> at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper$2.run(DirectoryApiConnectionWrapper.java:395)
> ... 6 moreCaused by:
> org.apache.directory.api.ldap.model.exception.LdapException:
> ERR_04170_TIMEOUT_OCCURED TimeOut occurred at
> org.apache.directory.ldap.client.api.LdapNetworkConnection.bind(LdapNetworkConnection.java:1549)
> ... 9 more
> ERR_04169_RESPONSE_QUEUE_EMPTIED The response queue has been emptied, no
> response was found.{code}
> In the haproxy log, I can see the connection was made. The ldap servers in
> the backed are definitely responding properly (I can connect to them
> directly, and numerous applications are using this haproxy as ldap source,
> and it works perfectly fine).
> I suspect it is something in M17.
> When I downgraded to 2.0.0.v20210213-M16, it works fine - I can connect as
> expected. I have tried M17 with java-16-jdk and java-11-openjdk, no change.
> Is there anything I could investigate more and help discovering what the
> issue might be?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
Re: Google Analytics removal
+1 However I don't see that we use GA. It seems it has been removed long time ago [1]. Only the privacy policy [2] still states that we'd use it so we should remove that paragraph. The privacy policy also mentions that we use tracking cookies which is not true, we don't set any cookie, so we can also remove that part, right? Best regards Stefan [1] https://lists.apache.org/thread/zspxxjhr5vw9kbr8hposn85ym6sfz485 [2] https://directory.apache.org/privacy-policy.html On 2/10/22 17:07, Emmanuel Lécharny wrote: Hi ! we have set up google analytics on Apache DS web site. It seems that it might cause issues with the european GDPR rules. I suggest we remove this feature we don't really use anyway. wdyt ? - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
Re: Question related to undefined filters
I understand it the same way as you, especially the next paragraph makes it clear that no error must be returned: Servers MUST NOT return errors if attribute descriptions or matching rule ids are not recognized, assertion values are invalid, or the assertion syntax is not supported. More details of filter processing are given in Clause 7.8 of [X.511]. TBH, as a user, I'd prefer to get a clear error when my filter is invalid (fail fast) than an empty result where I don't understand why. This doesn't follow the principle of least surprise... Kind regards, Stefan On 1/12/22 11:12, Emmanuel Lécharny wrote: Hi! recently, I was working on fixing a NPE in the server. Thtis was due to a wrong filter being sent, where a Substring filter was used for an attribute that does not have a SunstringMR (uniqueMmeber). The filter was like (uniqueMmeber=abc*). RFC 4511 is not absolutely clear about what to do in this case, or should I say, I'm not absolutely sure I understand what it says: A server MUST evaluate filters according to the three-valued logic of [X.511] (1993), Clause 7.8.1. In summary, a filter is evaluated to "TRUE", "FALSE", or "Undefined". If the filter evaluates to TRUE for a particular entry, then the attributes of that entry are returned as part of the Search result (subject to any applicable access control restrictions). If the filter evaluates to FALSE or Undefined, then the entry is ignored for the Search. A filter of the "and" choice is TRUE if all the filters in the SET OF evaluate to TRUE, FALSE if at least one filter is FALSE, and Undefined otherwise. A filter of the "or" choice is FALSE if all the filters in the SET OF evaluate to FALSE, TRUE if at least one filter is TRUE, and Undefined otherwise. A filter of the 'not' choice is TRUE if the filter being negated is FALSE, FALSE if it is TRUE, and Undefined if it is Undefined. A filter item evaluates to Undefined when the server would not be able to determine whether the assertion value matches an entry. Examples include: - An attribute description in an equalityMatch, substrings, greaterOrEqual, lessOrEqual, approxMatch, or extensibleMatch filter is not recognized by the server. - The attribute type does not define the appropriate matching rule. - A MatchingRuleId in the extensibleMatch is not recognized by the server or is not valid for the attribute type. - The type of filtering requested is not implemented. - The assertion value is invalid. For example, if a server did not recognize the attribute type shoeSize, the filters (shoeSize=*), (shoeSize=12), (shoeSize>=12), and (shoeSize<=12) would each evaluate to Undefined. AFAICU, an entry having a uniqueMember attribute should simply noit be returned when the bad filter is used. I'm fine with this logic, assuming this is the correct one. Any remark or clarification ? Many thanks ! - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
Re: New Fortress Images for OpenLDAP and ApacheDS are really a release and should be voted on
On 1/2/22 16:57, Shawn McKinney wrote: Hello, I’ve posted a bit on fortress list about new docker images. * [Proposal for Updated Docker Image for OpenLDAP FC-305](https://lists.apache.org/thread/2chz3wz3fvz65fkjjmt9sg67p3qnzxvd) * [Proposal for Updated Docker Image for ApacheDS FC-306](https://lists.apache.org/thread/5ty64o3q4zq1wg3z6bsoy7cmf275jvz4) There are a couple of tickets created to track the progress: * [Upgrade OpenLDAP Docker Container](https://issues.apache.org/jira/browse/FC-305) * [Upgrade ApacheDS Docker Container](https://issues.apache.org/jira/browse/FC-306) Besides bring your attention to these proposed changes before I push the updated images to Dockerhub I wanted to bring up the obvious fact that publishing images is a lot like a release. So, should we be voting on image updates on Dockerhub? I don't think so. The purpose of those Docker images is to simplify testing of Fortress. Those are no official images of our products (Fortress, ApacheDS). Kind regards, Stefan - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (FC-305) Upgrade OpenLDAP Docker Container
[ https://issues.apache.org/jira/browse/FC-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17467709#comment-17467709 ] Stefan Seelmann commented on FC-305: +1, sounds good to me. The increase of 40 MB is worth it. > Upgrade OpenLDAP Docker Container > - > > Key: FC-305 > URL: https://issues.apache.org/jira/browse/FC-305 > Project: FORTRESS > Issue Type: Improvement >Affects Versions: 2.0.7 >Reporter: Shawn McKinney >Assignee: Shawn McKinney >Priority: Major > Fix For: 2.0.8 > > > A number of improvements: > - upgrade to OpenLDAP 2.5 > - run as non-root user > - update slapd.conf, schema supports, ACL's -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (FC-306) Upgrade ApacheDS Docker Container
[ https://issues.apache.org/jira/browse/FC-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17467708#comment-17467708 ] Stefan Seelmann commented on FC-306: +1, sounds great, thanks Shawn! > Upgrade ApacheDS Docker Container > - > > Key: FC-306 > URL: https://issues.apache.org/jira/browse/FC-306 > Project: FORTRESS > Issue Type: Improvement >Affects Versions: 2.0.7 >Reporter: Shawn McKinney >Assignee: Shawn McKinney >Priority: Major > Fix For: 2.0.8 > > > Use: > a) FROM openjdk:11-jre-slim-buster > b) ENV APACHEDS_VERSION=2.0.0.AM25 > Slim image: > before: 554MB > after: 251MB > Other benefits: > 1. use recent jdk > 2. " apacheds release -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
Re: Apache Directory Studio 2.0.0.v20151221-M10 prone to CVE-2021-44228
Hi Peter, first of all to be clear, you ask about a 6 year old version of Apache Directory Studio, correct? I looked into that jar, it's the Apache Ant Log4 Listener only. The log4j library itself is not included (neither in version 1 nor 2). ``` $ unzip -l ./plugins/org.apache.ant_1.9.2.v201404171502/lib/ant-apache-log4j.jar Archive: ./plugins/org.apache.ant_1.9.2.v201404171502/lib/ant-apache-log4j.jar Length DateTimeName - -- - 0 2013-07-08 20:17 META-INF/ 432 2013-07-08 20:17 META-INF/MANIFEST.MF 0 2013-07-08 20:16 org/ 0 2013-07-08 20:16 org/apache/ 0 2013-07-08 20:17 org/apache/tools/ 0 2013-07-08 20:17 org/apache/tools/ant/ 0 2013-07-08 20:17 org/apache/tools/ant/listener/ 3446 2013-07-08 20:17 org/apache/tools/ant/listener/Log4jListener.class 15289 2013-07-08 20:16 META-INF/LICENSE.txt 218 2013-07-08 20:16 META-INF/NOTICE.txt - --- 19385 10 files ``` Kind regards, Stefan On 12/21/21 18:41, peter.br...@ruv.de wrote: Hello, could you please give us a short information if Apache Directory Studio is prone to CVE-2021-44228. We have seen that a log4j is included ./Apache Directory Studio\plugins\org.apache.ant_1.9.2.v201404171502\lib\ant-apache-log4j.jar But we don't know if it has any impact in respect to the security issue. Best regards, Peter Brodt - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Deleted] (DIR-340) Salam Joker
[ https://issues.apache.org/jira/browse/DIR-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann deleted DIR-340: > Salam Joker > --- > > Key: DIR-340 > URL: https://issues.apache.org/jira/browse/DIR-340 > Project: Directory > Issue Type: Improvement >Reporter: JoKero >Assignee: Emmanuel Lécharny >Priority: Major > Labels: performance > Original Estimate: 2,016h > Remaining Estimate: 2,016h > > Ketelitian, evaluasi dan improvement selalu diperlukan ketika developer > membangun website yang akan diluncurkan. Begitu juga dengan situs Joker > Gaming yang satu ini Joker188, agar siap diperkenalkan pada berbagai > directory online gaming yang tepat, serta platform yang mendukung. > Bagi Anda yang sedang kepo dengan permainan dengan berbagai nama ini, ada > yang mengatakannya Joker128, Joker388 serta game Joker188 Slot, sila kunjungi > pada link alternatif ini [https://188.166.225.61|https://188.166.225.61/] > Mampirlah dan boleh melakukan registrasi agar bisa ikut bermain. > Salam Joker dari Jokero Slotter Mania -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Comment Edited] (DIRSTUDIO-1290) Setup custom Java path that have a space in name nor working
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17415554#comment-17415554
]
Stefan Seelmann edited comment on DIRSTUDIO-1290 at 9/15/21, 2:33 PM:
--
Which Studio version do you use? I see that your ini file contains
{{-Dosgi.requiredJavaVersion=1.8}}, but since Studio 2.0.0-M16 it requires Java
11. Is that an ini file from a previous installation maybe? Please change it to
{{-Dosgi.requiredJavaVersion=11}}.
was (Author: seelmann):
Which Studio version do you use? I see that your ini file contains {{-vmargs
-Dosgi.requiredJavaVersion=1.8 }}, but since Studio 2.0.0-M16 it requires Java
11. Is that an ini file from a previous installation maybe? Please change it to
{{-Dosgi.requiredJavaVersion=11}}.
> Setup custom Java path that have a space in name nor working
>
>
> Key: DIRSTUDIO-1290
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1290
> Project: Directory Studio
> Issue Type: Question
> Components: studio-apacheds-configuration
>Reporter: Philipp Homberger
>Priority: Minor
> Attachments: image-2021-09-15-07-48-14-809.png
>
>
> h3.
> https://directory.apache.org/studio/faqs.html#how-to-set-the-java-vm-to-use
> h3. How to set the Java VM to use?
> Add the following content to _ApacheDirectoryStudio.ini_ file (before the
> “-vmargs” line):
>
> {{-vm
> }}
> *Not woring with a path that have space in the name like C:/Program
> Files/java/java.exe*{{}}
> I have try with Quotes uws.
> But I jave at the moment no Idea. {{}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRSTUDIO-1290) Setup custom Java path that have a space in name nor working
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17415554#comment-17415554
]
Stefan Seelmann commented on DIRSTUDIO-1290:
Which Studio version do you use? I see that your ini file contains {{-vmargs
-Dosgi.requiredJavaVersion=1.8 }}, but since Studio 2.0.0-M16 it requires Java
11. Is that an ini file from a previous installation maybe? Please change it to
{{-Dosgi.requiredJavaVersion=11}}.
> Setup custom Java path that have a space in name nor working
>
>
> Key: DIRSTUDIO-1290
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1290
> Project: Directory Studio
> Issue Type: Question
> Components: studio-apacheds-configuration
>Reporter: Philipp Homberger
>Priority: Minor
> Attachments: image-2021-09-15-07-48-14-809.png
>
>
> h3.
> https://directory.apache.org/studio/faqs.html#how-to-set-the-java-vm-to-use
> h3. How to set the Java VM to use?
> Add the following content to _ApacheDirectoryStudio.ini_ file (before the
> “-vmargs” line):
>
> {{-vm
> }}
> *Not woring with a path that have space in the name like C:/Program
> Files/java/java.exe*{{}}
> I have try with Quotes uws.
> But I jave at the moment no Idea. {{}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Comment Edited] (DIRSTUDIO-1290) Setup custom Java path that have a space in name nor working
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17415319#comment-17415319
]
Stefan Seelmann edited comment on DIRSTUDIO-1290 at 9/15/21, 4:56 AM:
--
I tested it on Windows 10 and it works. I used the backslash \ instead of
forward slack /, maybe that's the reason?
Here is the full ini file for reference:
{noformat}
-startup
plugins/org.eclipse.equinox.launcher_1.6.0.v20200915-1508.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_64_1.2.0.v20200915-1442
/studio-rcp/resources/icons/linux/studio.xpm
###
#Uncomment_to_configure_the_language
#https://directory.apache.org/studio/faqs.html#how-to-set-the-language-of-studio
#-nl
#en
###
#Uncomment_to_configure_Java_version_to_use
#https://directory.apache.org/studio/faqs.html#how-to-set-the-java-vm-to-use
-vm
C:\Program Files\AdoptOpenJDK\jdk-11.0.11.9-hotspot - Copy\bin\java.exe
-vmargs
-Dosgi.requiredJavaVersion=11
###
#Uncomment_to_configure_heap_memory
#https://directory.apache.org/studio/faqs.html#how-to-increase-the-heap-memory
#-Xms1g
#-Xmx2g
{noformat}
was (Author: seelmann):
I tested it on Windows 10 and it works. I used the backslash \ instead of
forward slack /, maybe that's the reason?
Here is the full ini file for reference:
{noformat}
-startup
plugins/org.eclipse.equinox.launcher_1.6.0.v20200915-1508.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_64_1.2.0.v20200915-1442
/studio-rcp/resources/icons/linux/studio.xpm
###
#Uncomment_to_configure_the_language
#https://directory.apache.org/studio/faqs.html#how-to-set-the-language-of-studio
#-nl
#en
###
#Uncomment_to_configure_Java_version_to_use
#https://directory.apache.org/studio/faqs.html#how-to-set-the-java-vm-to-use
-vm
C:\Program Files\AdoptOpenJDK\jdk-11.0.11.9-hotspot - Copy\bin\java.exe
-vmargs
-Dosgi.requiredJavaVersion=11
###-startup
plugins/org.eclipse.equinox.launcher_1.6.0.v20200915-1508.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_64_1.2.0.v20200915-1442
/studio-rcp/resources/icons/linux/studio.xpm
###
#Uncomment_to_configure_the_language
#https://directory.apache.org/studio/faqs.html#how-to-set-the-language-of-studio
#-nl
#en
###
#Uncomment_to_configure_Java_version_to_use
#https://directory.apache.org/studio/faqs.html#how-to-set-the-java-vm-to-use
-vm
C:\Program Files\AdoptOpenJDK\jdk-11.0.11.9-hotspot - Copy\bin\java.exe
-vmargs
-Dosgi.requiredJavaVersion=11
###
#Uncomment_to_configure_heap_memory
#https://directory.apache.org/studio/faqs.html#how-to-increase-the-heap-memory
#-Xms1g
#-Xmx2g
#Uncomment_to_configure_heap_memory
#https://directory.apache.org/studio/faqs.html#how-to-increase-the-heap-memory
#-Xms1g
#-Xmx2g
{noformat}
> Setup custom Java path that have a space in name nor working
>
>
> Key: DIRSTUDIO-1290
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1290
> Project: Directory Studio
> Issue Type: Question
> Components: studio-apacheds-configuration
>Reporter: Philipp Homberger
>Priority: Minor
>
> h3.
> https://directory.apache.org/studio/faqs.html#how-to-set-the-java-vm-to-use
> h3. How to set the Java VM to use?
> Add the following content to _ApacheDirectoryStudio.ini_ file (before the
> “-vmargs” line):
>
> {{-vm
> }}
> *Not woring with a path that have space in the name like C:/Program
> Files/java/java.exe*{{}}
> I have try with Quotes uws.
> But I jave at the moment no Idea. {{}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRSTUDIO-1290) Setup custom Java path that have a space in name nor working
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17415319#comment-17415319
]
Stefan Seelmann commented on DIRSTUDIO-1290:
I tested it on Windows 10 and it works. I used the backslash \ instead of
forward slack /, maybe that's the reason?
Here is the full ini file for reference:
{noformat}
-startup
plugins/org.eclipse.equinox.launcher_1.6.0.v20200915-1508.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_64_1.2.0.v20200915-1442
/studio-rcp/resources/icons/linux/studio.xpm
###
#Uncomment_to_configure_the_language
#https://directory.apache.org/studio/faqs.html#how-to-set-the-language-of-studio
#-nl
#en
###
#Uncomment_to_configure_Java_version_to_use
#https://directory.apache.org/studio/faqs.html#how-to-set-the-java-vm-to-use
-vm
C:\Program Files\AdoptOpenJDK\jdk-11.0.11.9-hotspot - Copy\bin\java.exe
-vmargs
-Dosgi.requiredJavaVersion=11
###-startup
plugins/org.eclipse.equinox.launcher_1.6.0.v20200915-1508.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_64_1.2.0.v20200915-1442
/studio-rcp/resources/icons/linux/studio.xpm
###
#Uncomment_to_configure_the_language
#https://directory.apache.org/studio/faqs.html#how-to-set-the-language-of-studio
#-nl
#en
###
#Uncomment_to_configure_Java_version_to_use
#https://directory.apache.org/studio/faqs.html#how-to-set-the-java-vm-to-use
-vm
C:\Program Files\AdoptOpenJDK\jdk-11.0.11.9-hotspot - Copy\bin\java.exe
-vmargs
-Dosgi.requiredJavaVersion=11
###
#Uncomment_to_configure_heap_memory
#https://directory.apache.org/studio/faqs.html#how-to-increase-the-heap-memory
#-Xms1g
#-Xmx2g
#Uncomment_to_configure_heap_memory
#https://directory.apache.org/studio/faqs.html#how-to-increase-the-heap-memory
#-Xms1g
#-Xmx2g
{noformat}
> Setup custom Java path that have a space in name nor working
>
>
> Key: DIRSTUDIO-1290
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1290
> Project: Directory Studio
> Issue Type: Question
> Components: studio-apacheds-configuration
>Reporter: Philipp Homberger
>Priority: Minor
>
> h3.
> https://directory.apache.org/studio/faqs.html#how-to-set-the-java-vm-to-use
> h3. How to set the Java VM to use?
> Add the following content to _ApacheDirectoryStudio.ini_ file (before the
> “-vmargs” line):
>
> {{-vm
> }}
> *Not woring with a path that have space in the name like C:/Program
> Files/java/java.exe*{{}}
> I have try with Quotes uws.
> But I jave at the moment no Idea. {{}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRSTUDIO-1288) LDIF not running on Directory Studio M17
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17402551#comment-17402551 ] Stefan Seelmann commented on DIRSTUDIO-1288: I'm afraid I can't reproduce it. I took your exact LDIF snippet and executed it via the LDIF editor and get an error in the modification logs view. Obviously, as I run it against OpenLDAP, it won't work, but it executes, the server returns an error, and the error is shown. I tested with both Java 11 and Java 16 on Linux. On a side note I admit we need to improve the error handling, the error popup should show a better message and more information. !screenshot-1.png! > LDIF not running on Directory Studio M17 > > > Key: DIRSTUDIO-1288 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1288 > Project: Directory Studio > Issue Type: Bug >Affects Versions: 2.0.0-M17 > Environment: PROD >Reporter: Gage Harris >Priority: Major > Attachments: screenshot-1.png > > > We just upgraded to Apache Directory Studio M17 from M14. In order to get > the app to open, we also had to upgrade to Java 16(openJDK 16.0.1). Everyone > on M17 can not run the ldif command shown below, but those on M14 can run the > same LDIF: > DN: uid=testusr,cn=testusers,ou=testservice,O=testorg > changetype:modify > replace: ibm-pwdIndividualPolicyDN > ibm-pwdIndividualPolicyDN: cn=servPwdPolicy, cn=ibmpolicies > > When we try to run this, we get a dialog popup that says 'Execute LDIF' has > encountered a problem. Error while executing LDIF - 1 errors occurred, see > logfile for details" > When looking at the error log we see this: > Plug-in: org.apache.directory.studio.common.core.jobs > "An exception stack trace is not available" > Session Data: > eclipse.buildId=unknown > java.version=16.0.1 > java.vendor=AdoptOpenJDK > BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_US > Framework arguments: /studio-rcp/resources/icons/linux/studio.xpm > Command-line arguments: -os win32 -ws win32 -arch x86_64 > /studio-rcp/resources/icons/linux/studio.xpm -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Updated] (DIRSTUDIO-1288) LDIF not running on Directory Studio M17
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann updated DIRSTUDIO-1288: --- Attachment: screenshot-1.png > LDIF not running on Directory Studio M17 > > > Key: DIRSTUDIO-1288 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1288 > Project: Directory Studio > Issue Type: Bug >Affects Versions: 2.0.0-M17 > Environment: PROD >Reporter: Gage Harris >Priority: Major > Attachments: screenshot-1.png > > > We just upgraded to Apache Directory Studio M17 from M14. In order to get > the app to open, we also had to upgrade to Java 16(openJDK 16.0.1). Everyone > on M17 can not run the ldif command shown below, but those on M14 can run the > same LDIF: > DN: uid=testusr,cn=testusers,ou=testservice,O=testorg > changetype:modify > replace: ibm-pwdIndividualPolicyDN > ibm-pwdIndividualPolicyDN: cn=servPwdPolicy, cn=ibmpolicies > > When we try to run this, we get a dialog popup that says 'Execute LDIF' has > encountered a problem. Error while executing LDIF - 1 errors occurred, see > logfile for details" > When looking at the error log we see this: > Plug-in: org.apache.directory.studio.common.core.jobs > "An exception stack trace is not available" > Session Data: > eclipse.buildId=unknown > java.version=16.0.1 > java.vendor=AdoptOpenJDK > BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_US > Framework arguments: /studio-rcp/resources/icons/linux/studio.xpm > Command-line arguments: -os win32 -ws win32 -arch x86_64 > /studio-rcp/resources/icons/linux/studio.xpm -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRSTUDIO-1288) LDIF not running on Directory Studio M17
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17402392#comment-17402392 ] Stefan Seelmann commented on DIRSTUDIO-1288: No, I mean the modification logs view, at the bottom center of the Studio UI. https://nightlies.apache.org/directory/studio/2.0.0.v20210717-M17/userguide/ldap_browser/tools_modification_logs_view.html https://nightlies.apache.org/directory/studio/2.0.0.v20210717-M17/userguide/ldap_browser/tools_ldap_perspective.html Also, how do you run the LDIF? Via the LDIF import wizard, or via the LDIF editor? > LDIF not running on Directory Studio M17 > > > Key: DIRSTUDIO-1288 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1288 > Project: Directory Studio > Issue Type: Bug >Affects Versions: 2.0.0-M17 > Environment: PROD >Reporter: Gage Harris >Priority: Major > > We just upgraded to Apache Directory Studio M17 from M14. In order to get > the app to open, we also had to upgrade to Java 16(openJDK 16.0.1). Everyone > on M17 can not run the ldif command shown below, but those on M14 can run the > same LDIF: > DN: uid=testusr,cn=testusers,ou=testservice,O=testorg > changetype:modify > replace: ibm-pwdIndividualPolicyDN > ibm-pwdIndividualPolicyDN: cn=servPwdPolicy, cn=ibmpolicies > > When we try to run this, we get a dialog popup that says 'Execute LDIF' has > encountered a problem. Error while executing LDIF - 1 errors occurred, see > logfile for details" > When looking at the error log we see this: > Plug-in: org.apache.directory.studio.common.core.jobs > "An exception stack trace is not available" > Session Data: > eclipse.buildId=unknown > java.version=16.0.1 > java.vendor=AdoptOpenJDK > BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_US > Framework arguments: /studio-rcp/resources/icons/linux/studio.xpm > Command-line arguments: -os win32 -ws win32 -arch x86_64 > /studio-rcp/resources/icons/linux/studio.xpm -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRSTUDIO-1288) LDIF not running on Directory Studio M17
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17402341#comment-17402341 ] Stefan Seelmann commented on DIRSTUDIO-1288: Can you please check the "Modification Logs", was there an error returned by the server? > LDIF not running on Directory Studio M17 > > > Key: DIRSTUDIO-1288 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1288 > Project: Directory Studio > Issue Type: Bug >Affects Versions: 2.0.0-M17 > Environment: PROD >Reporter: Gage Harris >Priority: Major > > We just upgraded to Apache Directory Studio M17 from M14. In order to get > the app to open, we also had to upgrade to Java 16(openJDK 16.0.1). Everyone > on M17 can not run the ldif command shown below, but those on M14 can run the > same LDIF: > DN: uid=testusr,cn=testusers,ou=testservice,O=testorg > changetype:modify > replace: ibm-pwdIndividualPolicyDN > ibm-pwdIndividualPolicyDN: cn=servPwdPolicy, cn=ibmpolicies > > When we try to run this, we get a dialog popup that says 'Execute LDIF' has > encountered a problem. Error while executing LDIF - 1 errors occurred, see > logfile for details" > When looking at the error log we see this: > Plug-in: org.apache.directory.studio.common.core.jobs > "An exception stack trace is not available" > Session Data: > eclipse.buildId=unknown > java.version=16.0.1 > java.vendor=AdoptOpenJDK > BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_US > Framework arguments: /studio-rcp/resources/icons/linux/studio.xpm > Command-line arguments: -os win32 -ws win32 -arch x86_64 > /studio-rcp/resources/icons/linux/studio.xpm -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRSTUDIO-1287) Error connecting to LDAPS server
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17401846#comment-17401846
]
Stefan Seelmann commented on DIRSTUDIO-1287:
In M17 we integrated LDAP API 2.1.0 which enables TLS 1.3
(https://issues.apache.org/jira/browse/DIRAPI-375) which seems it was a mistake
as https://issues.apache.org/jira/browse/DIRMINA-1132 seems to be an issue
after all.
In your debug log I see {{TLS13 alert}} so I assume it's related.
> Error connecting to LDAPS server
>
>
> Key: DIRSTUDIO-1287
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1287
> Project: Directory Studio
> Issue Type: Bug
>Affects Versions: 2.0.0-M17
>Reporter: Robin
>Priority: Major
>
> In trying to connect to an LDAP server via TLS I have run into what I believe
> to be a bug.
> The LDAP server is the built-in one on a Synology NAS with a valid
> certificate installed.
> I am able to successfully bind to it using LDAPS on port 636 using
> javax.naming:
> {code:java}
> Hashtable env = new Hashtable();
> env.put(Context.INITIAL_CONTEXT_FACTORY,
> "com.sun.jndi.ldap.LdapCtxFactory");
> env.put(Context.PROVIDER_URL, ldapUrl);
> env.put(Context.SECURITY_AUTHENTICATION, authentication);
> env.put(Context.SECURITY_PRINCIPAL, bindDN);
> env.put(Context.SECURITY_CREDENTIALS, password);
> return new InitialLdapContext (env, null);
> {code}
> However, when trying to connect using Apache Directory Studio I keep getting
> an error:
> The authentication failed ERR_04169_RESPONSE_QUEUE_EMPTIED The response queue
> has been emptied, no response was found.
> I started Directory Studio with -Djavax.net.debug=all to see what happens and
> this is what I found:
> * There's a bunch of logging which eventually ends with this line:
> {code:java}
> javax.net.ssl|ALL|34|NioProcessor-5|2021-08-19 09:52:20.548
> BST|SSLSessionImpl.java:242|Session initialized:
> Session(1629363140485|TLS_AES_128_GCM_SHA256){code}
> * It then idles for a while after which this happens:
> {code:java}
> javax.net.ssl|ALL|32|Worker-4: Open Connection|2021-08-19 09:52:50.512
> BST|SSLEngineImpl.java:752|Closing outbound of SSLEngine
> javax.net.ssl|WARNING|32|Worker-4: Open Connection|2021-08-19 09:52:50.512
> BST|SSLEngineOutputRecord.java:168|outbound has closed, ignore outbound
> application data
> javax.net.ssl|DEBUG|32|Worker-4: Open Connection|2021-08-19 09:52:50.512
> BST|SSLEngineOutputRecord.java:505|WRITE: TLS13 alert, length = 2
> javax.net.ssl|DEBUG|32|Worker-4: Open Connection|2021-08-19 09:52:50.512
> BST|SSLCipher.java:2036|Plaintext before ENCRYPTION (
> : 01 00 15 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0010: 00 00 00 ...
> )
> javax.net.ssl|DEBUG|32|Worker-4: Open Connection|2021-08-19 09:52:50.512
> BST|SSLEngineOutputRecord.java:523|Raw write (
> : 17 03 03 00 23 00 65 A2 9A C7 DD 2C 23 8D 18 75 #.e,#..u
> 0010: 98 7F 17 DD 3B 01 61 36 C8 83 9A E1 0D 41 B0 00 ;.a6.A..
> 0020: 07 8D 20 48 EB 1E 31 7B.. H..1.
> )
> javax.net.ssl|ALL|34|NioProcessor-5|2021-08-19 09:52:50.513
> BST|SSLEngineImpl.java:724|Closing inbound of SSLEngine
> javax.net.ssl|ERROR|34|NioProcessor-5|2021-08-19 09:52:50.514
> BST|TransportContext.java:341|Fatal (INTERNAL_ERROR): closing inbound before
> receiving peer's close_notify (
> "throwable" : {
> javax.net.ssl.SSLException: closing inbound before receiving peer's
> close_notify
> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:133)
> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
> at
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:336)
> at
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:292)
> at
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:283)
> at
> java.base/sun.security.ssl.SSLEngineImpl.closeInbound(SSLEngineImpl.java:733)
> at org.apache.mina.filter.ssl.SslHandler.destroy(SslHandler.java:209)
> at
> org.apache.mina.filter.ssl.SslFilter.sessionClosed(SslFilter.java:485)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextSessionClosed(DefaultIoFilterChain.java:606)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChai
[jira] [Updated] (DIRSTUDIO-1286) Windows installer: the software version is missing
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann updated DIRSTUDIO-1286: --- Fix Version/s: 2.0.0-M18 > Windows installer: the software version is missing > -- > > Key: DIRSTUDIO-1286 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1286 > Project: Directory Studio > Issue Type: Improvement > Components: studio-installer >Affects Versions: 2.0.0-M17 > Environment: Windows 10 >Reporter: Elvis Bortoletto >Priority: Minor > Fix For: 2.0.0-M18 > > Attachments: image-2021-08-17-18-31-32-731.png, > image-2021-08-17-18-32-47-581.png > > > Once installed the Directory Studio, the version is not reported in "Control > Panel | Programs and Features". > !image-2021-08-17-18-32-47-581.png! > As a side effect, "winget upgrade" gets confused, reporting the Directory > Studio in the list of the packages with an available upgrade. > !image-2021-08-17-18-31-32-731.png! > Maybe reporting the software version would enhance the user experience and > would fix the winget behavior. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Resolved] (DIRSTUDIO-1286) Windows installer: the software version is missing
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann resolved DIRSTUDIO-1286. Resolution: Fixed > Windows installer: the software version is missing > -- > > Key: DIRSTUDIO-1286 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1286 > Project: Directory Studio > Issue Type: Improvement > Components: studio-installer >Affects Versions: 2.0.0-M17 > Environment: Windows 10 >Reporter: Elvis Bortoletto >Priority: Minor > Fix For: 2.0.0-M18 > > Attachments: image-2021-08-17-18-31-32-731.png, > image-2021-08-17-18-32-47-581.png > > > Once installed the Directory Studio, the version is not reported in "Control > Panel | Programs and Features". > !image-2021-08-17-18-32-47-581.png! > As a side effect, "winget upgrade" gets confused, reporting the Directory > Studio in the list of the packages with an available upgrade. > !image-2021-08-17-18-31-32-731.png! > Maybe reporting the software version would enhance the user experience and > would fix the winget behavior. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRSTUDIO-1286) Windows installer: the software version is missing
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17401839#comment-17401839 ] Stefan Seelmann commented on DIRSTUDIO-1286: Great, thank for reporting and the patch :) > Windows installer: the software version is missing > -- > > Key: DIRSTUDIO-1286 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1286 > Project: Directory Studio > Issue Type: Improvement > Components: studio-installer >Affects Versions: 2.0.0-M17 > Environment: Windows 10 >Reporter: Elvis Bortoletto >Priority: Minor > Fix For: 2.0.0-M18 > > Attachments: image-2021-08-17-18-31-32-731.png, > image-2021-08-17-18-32-47-581.png > > > Once installed the Directory Studio, the version is not reported in "Control > Panel | Programs and Features". > !image-2021-08-17-18-32-47-581.png! > As a side effect, "winget upgrade" gets confused, reporting the Directory > Studio in the list of the packages with an available upgrade. > !image-2021-08-17-18-31-32-731.png! > Maybe reporting the software version would enhance the user experience and > would fix the winget behavior. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRSTUDIO-1286) Windows installer: the software version is missing
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17401278#comment-17401278 ] Stefan Seelmann commented on DIRSTUDIO-1286: Thanks for the proposal. I added the change here: https://github.com/apache/directory-studio/commit/37d3378f38d8347647a1402b560960a21e4dbbc7 and uploaded the Windows installer here, in case you want to try it out: https://home.apache.org/~seelmann/ > Windows installer: the software version is missing > -- > > Key: DIRSTUDIO-1286 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1286 > Project: Directory Studio > Issue Type: Improvement > Components: studio-installer >Affects Versions: 2.0.0-M17 > Environment: Windows 10 >Reporter: Elvis Bortoletto >Priority: Minor > Attachments: image-2021-08-17-18-31-32-731.png, > image-2021-08-17-18-32-47-581.png > > > Once installed the Directory Studio, the version is not reported in "Control > Panel | Programs and Features". > !image-2021-08-17-18-32-47-581.png! > As a side effect, "winget upgrade" gets confused, reporting the Directory > Studio in the list of the packages with an available upgrade. > !image-2021-08-17-18-31-32-731.png! > Maybe reporting the software version would enhance the user experience and > would fix the winget behavior. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Comment Edited] (DIRSTUDIO-1285) Proxied auth leads to wrong DIT/rootDSE being used
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17398875#comment-17398875
]
Stefan Seelmann edited comment on DIRSTUDIO-1285 at 8/13/21, 7:23 PM:
--
The reason that "dc=baz,dc=quux" is not shown as context entry in the DIT is
that for a base object search no entry is returned, see the extract of the logs
you provided below. Can you try to run that ldapsearch command and maybe vary
it a bit (filter, returned attributes)? Is there an access control in place
that this entry is not visible for the used user?
{noformat}
#!SEARCH REQUEST (14) OK
#!CONNECTION ldap://baz.domain.tld:389
#!DATE 2021-08-13T05:44:34.364
# LDAP URL :
ldap://baz.domain.tld:389/dc=baz,dc=quux?hasSubordinates,objectClass??(objectClass=*)
# command line : ldapsearch -H ldap://baz.domain.tld:389 -ZZ -x -D
"cn=joe,dc=foo,dc=bar" -W -b "dc=baz,dc=quux" -s base -a always -z 1
"(objectClass=*)" "hasSubordinates" "objectClass"
# baseObject : dc=baz,dc=quux
# scope: baseObject (0)
# derefAliases : derefAlways (3)
# sizeLimit: 1
# timeLimit: 0
# typesOnly: False
# filter : (objectClass=*)
# attributes : hasSubordinates objectClass
#!SEARCH RESULT DONE (14) OK
#!CONNECTION ldap://baz.domain.tld:389
#!DATE 2021-08-13T05:44:34.385
# numEntries : 0
{noformat}
was (Author: seelmann):
The reason that "dc=baz,dc=quux" is shown as context entry in the DIT is that
for a base object search no entry is returned, see the extract of the logs you
provided below. Can you try to run that ldapsearch command and maybe vary it a
bit (filter, returned attributes)? Is there an access control in place that
this entry is not visible for the used user?
{noformat}
#!SEARCH REQUEST (14) OK
#!CONNECTION ldap://baz.domain.tld:389
#!DATE 2021-08-13T05:44:34.364
# LDAP URL :
ldap://baz.domain.tld:389/dc=baz,dc=quux?hasSubordinates,objectClass??(objectClass=*)
# command line : ldapsearch -H ldap://baz.domain.tld:389 -ZZ -x -D
"cn=joe,dc=foo,dc=bar" -W -b "dc=baz,dc=quux" -s base -a always -z 1
"(objectClass=*)" "hasSubordinates" "objectClass"
# baseObject : dc=baz,dc=quux
# scope: baseObject (0)
# derefAliases : derefAlways (3)
# sizeLimit: 1
# timeLimit: 0
# typesOnly: False
# filter : (objectClass=*)
# attributes : hasSubordinates objectClass
#!SEARCH RESULT DONE (14) OK
#!CONNECTION ldap://baz.domain.tld:389
#!DATE 2021-08-13T05:44:34.385
# numEntries : 0
{noformat}
> Proxied auth leads to wrong DIT/rootDSE being used
> --
>
> Key: DIRSTUDIO-1285
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1285
> Project: Directory Studio
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: brent s.
>Priority: Major
> Attachments: connect_disconnect.log, enable_base_dn_server.log
>
>
> If using Apache Directory Studio as a client to OpenLDAP using [remote
> bind|https://www.openldap.org/faq/data/cache/532.html] (see *Identity
> Assertion*), the incorrect DIT/rootDSE is used and the proper DIT/rootDSE is
> seemingly never detected.
> For example, the following scenario:
>
> BindDN (as configured in the connection profile): _cn=joe,dc=foo,dc=bar_
> Server (as configured in the connection profile): _ldap://baz.domain.tld:389_
> _ldap://baz.domain.tld:389_ contains *dc=baz,dc=quux*.
> *dc=baz,dc=quux* is configured to proxy all bind requests for *anything under
> dc=foo,dc=bar* to proxy (back-ldap) the bind request to
> _ldap://foo.domain.tld:389_ using identity assertion.
> _ldap://foo.domain.tld:389_ obviously contains *dc=foo,dc=bar*.
>
>
> When the above bindDN and Server is used, binding successfully takes place.
> However, the only DIT/rootDSE visible is *dc=foo,dc=bar* and _*not*_
> *dc=baz,dc=quux*! In other words, the DIT that exists on the actual server.
> This is, obviously, incorrect.
> This is handled correctly in the openLDAP clients (e.g. _ldapsearch_).
>
> Ensuring "Get base DNs from Root DSE" is checked in the connection profile
> does not change this behavior. _Ensuring that is disabled and specifying
> e.g._ *dc=baz,dc=quux* _manually as the base DN does not change this
> behavior!_ Using the "Fetch Base DNs" button does not change this behavior;
> it only detects *dc=foo,dc=bar*.
>
> I can see both DIT DNs in the root DSE's _namingContexts_ attributes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRSTUDIO-1285) Proxied auth leads to wrong DIT/rootDSE being used
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17398875#comment-17398875
]
Stefan Seelmann commented on DIRSTUDIO-1285:
The reason that "dc=baz,dc=quux" is shown as context entry in the DIT is that
for a base object search no entry is returned, see the extract of the logs you
provided below. Can you try to run that ldapsearch command and maybe vary it a
bit (filter, returned attributes)? Is there an access control in place that
this entry is not visible for the used user?
{noformat}
#!SEARCH REQUEST (14) OK
#!CONNECTION ldap://baz.domain.tld:389
#!DATE 2021-08-13T05:44:34.364
# LDAP URL :
ldap://baz.domain.tld:389/dc=baz,dc=quux?hasSubordinates,objectClass??(objectClass=*)
# command line : ldapsearch -H ldap://baz.domain.tld:389 -ZZ -x -D
"cn=joe,dc=foo,dc=bar" -W -b "dc=baz,dc=quux" -s base -a always -z 1
"(objectClass=*)" "hasSubordinates" "objectClass"
# baseObject : dc=baz,dc=quux
# scope: baseObject (0)
# derefAliases : derefAlways (3)
# sizeLimit: 1
# timeLimit: 0
# typesOnly: False
# filter : (objectClass=*)
# attributes : hasSubordinates objectClass
#!SEARCH RESULT DONE (14) OK
#!CONNECTION ldap://baz.domain.tld:389
#!DATE 2021-08-13T05:44:34.385
# numEntries : 0
{noformat}
> Proxied auth leads to wrong DIT/rootDSE being used
> --
>
> Key: DIRSTUDIO-1285
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1285
> Project: Directory Studio
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: brent s.
>Priority: Major
> Attachments: connect_disconnect.log, enable_base_dn_server.log
>
>
> If using Apache Directory Studio as a client to OpenLDAP using [remote
> bind|https://www.openldap.org/faq/data/cache/532.html] (see *Identity
> Assertion*), the incorrect DIT/rootDSE is used and the proper DIT/rootDSE is
> seemingly never detected.
> For example, the following scenario:
>
> BindDN (as configured in the connection profile): _cn=joe,dc=foo,dc=bar_
> Server (as configured in the connection profile): _ldap://baz.domain.tld:389_
> _ldap://baz.domain.tld:389_ contains *dc=baz,dc=quux*.
> *dc=baz,dc=quux* is configured to proxy all bind requests for *anything under
> dc=foo,dc=bar* to proxy (back-ldap) the bind request to
> _ldap://foo.domain.tld:389_ using identity assertion.
> _ldap://foo.domain.tld:389_ obviously contains *dc=foo,dc=bar*.
>
>
> When the above bindDN and Server is used, binding successfully takes place.
> However, the only DIT/rootDSE visible is *dc=foo,dc=bar* and _*not*_
> *dc=baz,dc=quux*! In other words, the DIT that exists on the actual server.
> This is, obviously, incorrect.
> This is handled correctly in the openLDAP clients (e.g. _ldapsearch_).
>
> Ensuring "Get base DNs from Root DSE" is checked in the connection profile
> does not change this behavior. _Ensuring that is disabled and specifying
> e.g._ *dc=baz,dc=quux* _manually as the base DN does not change this
> behavior!_ Using the "Fetch Base DNs" button does not change this behavior;
> it only detects *dc=foo,dc=bar*.
>
> I can see both DIT DNs in the root DSE's _namingContexts_ attributes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRSTUDIO-1285) Proxied auth leads to wrong DIT/rootDSE being used
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17398275#comment-17398275 ] Stefan Seelmann commented on DIRSTUDIO-1285: bq. Full version string is 2.0.0.v20210213-M16. I've followed the procedure above but both the log window and the exported log file is completely empty, even with Search Result Entry Logs enabled, before, during, and after the connection and disconnect. This is a known bug in this version. Can you please try to latest version 2.0.0.v20210717-M17 that was release 2 weeks ago? (It also solves some issues with the namingContexts, even if yours sounds different, see changelog https://directory.apache.org/studio/changelog.html) > Proxied auth leads to wrong DIT/rootDSE being used > -- > > Key: DIRSTUDIO-1285 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1285 > Project: Directory Studio > Issue Type: Bug >Affects Versions: 2.0.0 >Reporter: brent s. >Priority: Major > > If using Apache Directory Studio as a client to OpenLDAP using [remote > bind|https://www.openldap.org/faq/data/cache/532.html] (see *Identity > Assertion*), the incorrect DIT/rootDSE is used and the proper DIT/rootDSE is > seemingly never detected. > For example, the following scenario: > > BindDN (as configured in the connection profile): _cn=joe,dc=foo,dc=bar_ > Server (as configured in the connection profile): _ldap://baz.domain.tld:389_ > _ldap://baz.domain.tld:389_ contains *dc=baz,dc=quux*. > *dc=baz,dc=quux* is configured to proxy all bind requests for *anything under > dc=foo,dc=bar* to proxy (back-ldap) the bind request to > _ldap://foo.domain.tld:389_ using identity assertion. > _ldap://foo.domain.tld:389_ obviously contains *dc=foo,dc=bar*. > > > When the above bindDN and Server is used, binding successfully takes place. > However, the only DIT/rootDSE visible is *dc=foo,dc=bar* and _*not*_ > *dc=baz,dc=quux*! In other words, the DIT that exists on the actual server. > This is, obviously, incorrect. > This is handled correctly in the openLDAP clients (e.g. _ldapsearch_). > > Ensuring "Get base DNs from Root DSE" is checked in the connection profile > does not change this behavior. _Ensuring that is disabled and specifying > e.g._ *dc=baz,dc=quux* _manually as the base DN does not change this > behavior!_ Using the "Fetch Base DNs" button does not change this behavior; > it only detects *dc=foo,dc=bar*. > > I can see both DIT DNs in the root DSE's _namingContexts_ attributes. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRSTUDIO-1285) Proxied auth leads to wrong DIT/rootDSE being used
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17398253#comment-17398253 ] Stefan Seelmann commented on DIRSTUDIO-1285: Which Studio version do you use? (full version string) So namingContexts contains both dc=baz,dc=quux and dc=foo,dc=bar, correct? Can you please clear the "Search Logs", enable the "Search Result Entry Logs" option, open the connection once, then post the "Search Logs" output (anonymize the data please). Disable the "Search Result Entry Logs" afterwards again as it logs a lot otherwise. https://nightlies.apache.org/directory/studio/2.0.0.v20210717-M17/userguide/ldap_browser/tools_search_logs_view.html > Proxied auth leads to wrong DIT/rootDSE being used > -- > > Key: DIRSTUDIO-1285 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1285 > Project: Directory Studio > Issue Type: Bug >Affects Versions: 2.0.0 >Reporter: brent s. >Priority: Major > > If using Apache Directory Studio as a client to OpenLDAP using [remote > bind|https://www.openldap.org/faq/data/cache/532.html] (see *Identity > Assertion*), the incorrect DIT/rootDSE is used and the proper DIT/rootDSE is > seemingly never detected. > For example, the following scenario: > > BindDN (as configured in the connection profile): _cn=joe,dc=foo,dc=bar_ > Server (as configured in the connection profile): _ldap://baz.domain.tld:389_ > _ldap://baz.domain.tld:389_ contains *dc=baz,dc=quux*. > *dc=baz,dc=quux* is configured to proxy all bind requests for *anything under > dc=foo,dc=bar* to proxy (back-ldap) the bind request to > _ldap://foo.domain.tld:389_ using identity assertion. > _ldap://foo.domain.tld:389_ obviously contains *dc=foo,dc=bar*. > > > When the above bindDN and Server is used, binding successfully takes place. > However, the only DIT/rootDSE visible is *dc=foo,dc=bar* and _*not*_ > *dc=baz,dc=quux*! In other words, the DIT that exists on the actual server. > This is, obviously, incorrect. > This is handled correctly in the openLDAP clients (e.g. _ldapsearch_). > > Ensuring "Get base DNs from Root DSE" is checked in the connection profile > does not change this behavior. _Ensuring that is disabled and specifying > e.g._ *dc=baz,dc=quux* _manually as the base DN does not change this > behavior!_ Using the "Fetch Base DNs" button does not change this behavior; > it only detects *dc=foo,dc=bar*. > > I can see both DIT DNs in the root DSE's _namingContexts_ attributes. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
Re: TCP keepalive time/interval/retry
On 8/2/21 5:08 PM, Radovan Semancik wrote: > Hello, > > I would like to implement support for setting TCP keepalive > time/interval/retry setting in the API. This is very useful for > long-lived LDAP connections, e.g. in case of connection pooling. > However, socket options for TCP keepalive time/interval/retry setting is > available since Java 11 (see class ExtendedSocketOptions). > > Now I'm a bit confused regarding Maven configuration. The directory API > has properties for Java 8 in pom.xml: > > 1.8 > 1.8 > > Yet, I would guess that otherwise we are on Java 11. Am I right? What > Java version we are actually supposed to run on? For Studio we dropped Java 8 support early this year, all other sub-projects are still compatible with Java 8. At some point we might drop Java 8 support too for all the other sub-projects. Feel free to open the discussion :) > Then, it looks like MINA is stuck back in Java 7 world. I had a look at > MINA source code (again) ... I'm not that well versed in MINA, yet it > looks like there is no obvious way how to use Java 11 > ExtendedSocketOptions in MINA (and hence Directory API). > > Am I right? This would be quite unfortunate, being stuck with > 10-year-old Java version. What would be the right thing to do here to > get API completely to Java 11 world? I'm trying to assess the required > effort, whether it would be feasible for us to do the work. I think you need to wait for Emmanuel, or ask the MINA people directly. Kind Regards, Stefan - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Comment Edited] (DIRSTUDIO-1284) Error while executing LDIF - [LDAP result code 53 - unwillingToPerform] - Must supply correct old password to change to new one
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17389780#comment-17389780
]
Stefan Seelmann edited comment on DIRSTUDIO-1284 at 7/29/21, 9:36 AM:
--
Which LDAP server do you use? Googling for the error message ("Must supply
correct old password to change to new one") reveals it's OpenLDAP and
especially the password policy overlay, but I better ask for it.
Can you also check in the "Modification Logs" view which modify operation is
sent in both Studio versions to the server? (don't post real passwords) Does it
send a combindes delete+add or a replace, see attached screenshot for an
example: !screenshot-1.png!
Last not least, since Studio version M16 there is support for the "Password
Modify Extended Operation" which provides better support for changing
passwords: Right-click on the entry -> Extended Operations -> Password Modify...
was (Author: seelmann):
Which LDAP server do you use? Googling for the error message ("Must supply
correct old password to change to new one") reveals it's OpenLDAP and
especially the password policy overlay, but I better ask for it.
Can you also check in the "Modification Logs" view which modify operation is
sent in both Studio versions to the server? Does it send a combindes delete+add
or a replace, see attached screenshot for an example: !screenshot-1.png!
Last not least, since Studio version M16 there is support for the "Password
Modify Extended Operation" which provides better support for changing
passwords: Right-click on the entry -> Extended Operations -> Password Modify...
> Error while executing LDIF - [LDAP result code 53 - unwillingToPerform] -
> Must supply correct old password to change to new one
> ---
>
> Key: DIRSTUDIO-1284
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1284
> Project: Directory Studio
> Issue Type: Bug
> Components: studio-ldifeditor
>Affects Versions: 2.0.0-M17
> Environment: Mac OS 11.4, running on a MacBook Pro (16-inch, 2019)
>Reporter: Katie Golan
>Priority: Major
> Fix For: 2.0.0-M15
>
> Attachments: Screen Shot 2021-07-06 at 9.22.13 AM.jpg, Screen Shot
> 2021-07-28 at 3.36.39 PM.png, screenshot-1.png
>
>
> The current version of Apache Directory Studio (2.0.0.v20210717-M17) seems to
> have a bug with password resets. I’ve confirmed that version
> {{2.0.0.v20200411-M15}} does not have this bug.
> # In Password Editor, the same password is entered for "Enter New Password"
> and "Confirm New Password"
> # When you click "OK", the following error results:
> "Error while executing LDIF
> - [LDAP result code 53 - unwillingToPerform] Must supply correct old
> password to change to new one"
>
> * I successfully reset the password for User A on version M15.
> * After upgrading to version M17, I got the above error when attempting a
> password reset for User A.
> * I then uninstalled Apache, rebooted, and reinstalled version M15.
> * After M15 reinstall, I was able to successfully reset User A's password
> again.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRSTUDIO-1284) Error while executing LDIF - [LDAP result code 53 - unwillingToPerform] - Must supply correct old password to change to new one
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17389780#comment-17389780
]
Stefan Seelmann commented on DIRSTUDIO-1284:
Which LDAP server do you use? Googling for the error message ("Must supply
correct old password to change to new one") reveals it's OpenLDAP and
especially the password policy overlay, but I better ask for it.
Can you also check in the "Modification Logs" view which modify operation is
sent in both Studio versions to the server? Does it send a combindes delete+add
or a replace, see attached screenshot for an example: !screenshot-1.png!
Last not least, since Studio version M16 there is support for the "Password
Modify Extended Operation" which provides better support for changing
passwords: Right-click on the entry -> Extended Operations -> Password Modify...
> Error while executing LDIF - [LDAP result code 53 - unwillingToPerform] -
> Must supply correct old password to change to new one
> ---
>
> Key: DIRSTUDIO-1284
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1284
> Project: Directory Studio
> Issue Type: Bug
> Components: studio-ldifeditor
>Affects Versions: 2.0.0-M17
> Environment: Mac OS 11.4, running on a MacBook Pro (16-inch, 2019)
>Reporter: Katie Golan
>Priority: Major
> Fix For: 2.0.0-M15
>
> Attachments: Screen Shot 2021-07-06 at 9.22.13 AM.jpg, Screen Shot
> 2021-07-28 at 3.36.39 PM.png, screenshot-1.png
>
>
> The current version of Apache Directory Studio (2.0.0.v20210717-M17) seems to
> have a bug with password resets. I’ve confirmed that version
> {{2.0.0.v20200411-M15}} does not have this bug.
> # In Password Editor, the same password is entered for "Enter New Password"
> and "Confirm New Password"
> # When you click "OK", the following error results:
> "Error while executing LDIF
> - [LDAP result code 53 - unwillingToPerform] Must supply correct old
> password to change to new one"
>
> * I successfully reset the password for User A on version M15.
> * After upgrading to version M17, I got the above error when attempting a
> password reset for User A.
> * I then uninstalled Apache, rebooted, and reinstalled version M15.
> * After M15 reinstall, I was able to successfully reset User A's password
> again.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Updated] (DIRSTUDIO-1284) Error while executing LDIF - [LDAP result code 53 - unwillingToPerform] - Must supply correct old password to change to new one
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seelmann updated DIRSTUDIO-1284:
---
Attachment: screenshot-1.png
> Error while executing LDIF - [LDAP result code 53 - unwillingToPerform] -
> Must supply correct old password to change to new one
> ---
>
> Key: DIRSTUDIO-1284
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1284
> Project: Directory Studio
> Issue Type: Bug
> Components: studio-ldifeditor
>Affects Versions: 2.0.0-M17
> Environment: Mac OS 11.4, running on a MacBook Pro (16-inch, 2019)
>Reporter: Katie Golan
>Priority: Major
> Fix For: 2.0.0-M15
>
> Attachments: Screen Shot 2021-07-06 at 9.22.13 AM.jpg, Screen Shot
> 2021-07-28 at 3.36.39 PM.png, screenshot-1.png
>
>
> The current version of Apache Directory Studio (2.0.0.v20210717-M17) seems to
> have a bug with password resets. I’ve confirmed that version
> {{2.0.0.v20200411-M15}} does not have this bug.
> # In Password Editor, the same password is entered for "Enter New Password"
> and "Confirm New Password"
> # When you click "OK", the following error results:
> "Error while executing LDIF
> - [LDAP result code 53 - unwillingToPerform] Must supply correct old
> password to change to new one"
>
> * I successfully reset the password for User A on version M15.
> * After upgrading to version M17, I got the above error when attempting a
> password reset for User A.
> * I then uninstalled Apache, rebooted, and reinstalled version M15.
> * After M15 reinstall, I was able to successfully reset User A's password
> again.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
CVE-2021-33900: Apache Directory Studio: StartTLS and SASL confidentiality protection bypass
Severity: high Description: While investigating DIRSTUDIO-1219 it was noticed that configured StartTLS encryption was not applied when any SASL authentication mechanism (DIGEST-MD5, GSSAPI) was used. While investigating DIRSTUDIO-1220 it was noticed that any configured SASL confidentiality layer was not applied. This issue affects Apache Directory Studio version 2.0.0.v20210213-M16 and prior versions. Mitigation: This issue was fixed in 2.0.0.v20210717-M17. All users using SASL are recommended to upgrade to Apache Directory Studio 2.0.0.v20210717-M17. Credit: Apache Directory would like to thank Hugh Cole-Baker for reporting this issue. - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[ANNOUNCE] Apache Directory Studio 2.0-0-M17 released
The Apache Directory Team is pleased to announce the release of Apache Directory Studio 2.0.0-M17. Apache Directory Studio is a complete directory tooling platform intended to be used with any LDAP server however it is particularly designed for use with ApacheDS. It is an Eclipse RCP application, composed of several Eclipse (OSGi) plugins, that can be easily upgraded with additional ones. These plugins can even run within Eclipse itself. You can download Apache Directory Studio 2.0.0-M17 as a standalone RCP application for macOS, Linux and Windows here: https://directory.apache.org/studio/downloads.html You can also install it directly in Eclipse using the marketplace or this update site: https://directory.apache.org/studio/update/ The full release notes can be found here: https://directory.apache.org/studio/changelog.html - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Updated] (DIRSTUDIO-1280) Studio browser connections to replicated LDAP dont work with Mac OS Big Sur
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann updated DIRSTUDIO-1280: --- Fix Version/s: 2.0.0-M17 > Studio browser connections to replicated LDAP dont work with Mac OS Big Sur > --- > > Key: DIRSTUDIO-1280 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1280 > Project: Directory Studio > Issue Type: Bug > Components: studio-ldapbrowser >Affects Versions: 2.0.0-M16 > Environment: Mac OS Big Sur 11.2.3 > Mac OS Big Sur 11.4 >Reporter: Sourabh Idoorkar >Priority: Major > Fix For: 2.0.0-M17 > > > I was using Apache Studio to connect to my LDAP which is setup in a > replicated topology. Mostly the LDAP Browser to view and edit data. This was > working fine. But recently my Mac went through the Big Sur update and since > then the studio browser to a replicated topology is not working. > I see the Root DSE as blank on the LDAP Browser > Reason I think this could be a Studio issue with the Mac Big Sur version > # I have investigated everything possible from my LDAP end and there have > been no recent changes to begin with > # I ended up trying Apache Studio from my Windows laptop and that worked > fine for the same LDAP. No issues with connection or browsing. That was with > M13 version > # I have since tried JXplorer to isolate if maybe its something to do with > MAC to LDAP connection rather than Studio to LDAP. But connections via > JXplorer work fine - view as well as edits > # Re-importing connections to Studio did not work - I thought maybe the > connections have a new format and the old one doesnt work anymore > # I tried it on a friend's laptop which is also MAC but older OS and it > works fine there > # Trying to run an older version M14 in the Mac Big Sur results in - > java.lang.NullPointerException: Cannot invoke > "org.eclipse.swt.internal.cocoa.NSGraphicsContext.graphicsPort()" because > "graphicsContext" is null -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Closed] (DIRSTUDIO-1280) Studio browser connections to replicated LDAP dont work with Mac OS Big Sur
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann closed DIRSTUDIO-1280. -- Resolution: Fixed > Studio browser connections to replicated LDAP dont work with Mac OS Big Sur > --- > > Key: DIRSTUDIO-1280 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1280 > Project: Directory Studio > Issue Type: Bug > Components: studio-ldapbrowser >Affects Versions: 2.0.0-M16 > Environment: Mac OS Big Sur 11.2.3 > Mac OS Big Sur 11.4 >Reporter: Sourabh Idoorkar >Priority: Major > Fix For: 2.0.0-M17 > > > I was using Apache Studio to connect to my LDAP which is setup in a > replicated topology. Mostly the LDAP Browser to view and edit data. This was > working fine. But recently my Mac went through the Big Sur update and since > then the studio browser to a replicated topology is not working. > I see the Root DSE as blank on the LDAP Browser > Reason I think this could be a Studio issue with the Mac Big Sur version > # I have investigated everything possible from my LDAP end and there have > been no recent changes to begin with > # I ended up trying Apache Studio from my Windows laptop and that worked > fine for the same LDAP. No issues with connection or browsing. That was with > M13 version > # I have since tried JXplorer to isolate if maybe its something to do with > MAC to LDAP connection rather than Studio to LDAP. But connections via > JXplorer work fine - view as well as edits > # Re-importing connections to Studio did not work - I thought maybe the > connections have a new format and the old one doesnt work anymore > # I tried it on a friend's laptop which is also MAC but older OS and it > works fine there > # Trying to run an older version M14 in the Mac Big Sur results in - > java.lang.NullPointerException: Cannot invoke > "org.eclipse.swt.internal.cocoa.NSGraphicsContext.graphicsPort()" because > "graphicsContext" is null -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Comment Edited] (DIRSTUDIO-1283) Generated update site is broken
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17386678#comment-17386678
]
Stefan Seelmann edited comment on DIRSTUDIO-1283 at 7/24/21, 8:58 AM:
--
As a workaround for 2.0.0-M17 release it's possible to delete the *.xml.xz
files, the Eclipse update will then fallback to the *.jar files which contain
the correct content.
https://lists.apache.org/thread.html/r29efa567f0638cb951e0c2dffbf161129d19e1970564879350719bfa%40%3Ccommits.directory.apache.org%3E
{noformat}
svn commit: r48977 - in
/release/directory/studio/2.0.0.v20210717-M17/update/dependencies:
artifacts.xml.xz artifacts.xml.xz.asc artifacts.xml.xz.sha256
artifacts.xml.xz.sha512 content.xml.xz content.xml.xz.asc content.xml.xz.sha256
content.xml.xz.sha512
Author: seelmann
Date: Sat Jul 24 08:32:41 2021
New Revision: 48977
Log:
DIRSTUDIO-1283: Workaround for broken update site: remove wrong xml.xz files,
fallback to jars
Removed:
release/directory/studio/2.0.0.v20210717-M17/update/dependencies/artifacts.xml.xz
release/directory/studio/2.0.0.v20210717-M17/update/dependencies/artifacts.xml.xz.asc
release/directory/studio/2.0.0.v20210717-M17/update/dependencies/artifacts.xml.xz.sha256
release/directory/studio/2.0.0.v20210717-M17/update/dependencies/artifacts.xml.xz.sha512
release/directory/studio/2.0.0.v20210717-M17/update/dependencies/content.xml.xz
release/directory/studio/2.0.0.v20210717-M17/update/dependencies/content.xml.xz.asc
release/directory/studio/2.0.0.v20210717-M17/update/dependencies/content.xml.xz.sha256
release/directory/studio/2.0.0.v20210717-M17/update/dependencies/content.xml.xz.sha512
{noformat}
was (Author: seelmann):
As a workaround for 2.0.0-M17 release it's possible to delete the *.xml.xz
files, the Eclipse update will then fallback to the *.jar files which contain
the correct content.
> Generated update site is broken
> ---
>
> Key: DIRSTUDIO-1283
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1283
> Project: Directory Studio
> Issue Type: Task
>Affects Versions: 2.0.0-M17
> Reporter: Stefan Seelmann
> Assignee: Stefan Seelmann
>Priority: Blocker
> Fix For: 2.0.0-M18
>
>
> The artifacts.xml.xz and content.xml.xz files that are generated for the
> update site dependencies is wrong, they only contains parts of the
> dependencies. This means that the update site doesn't work.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRSTUDIO-1283) Generated update site is broken
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17386678#comment-17386678 ] Stefan Seelmann commented on DIRSTUDIO-1283: As a workaround for 2.0.0-M17 release it's possible to delete the *.xml.xz files, the Eclipse update will then fallback to the *.jar files which contain the correct content. > Generated update site is broken > --- > > Key: DIRSTUDIO-1283 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1283 > Project: Directory Studio > Issue Type: Task >Affects Versions: 2.0.0-M17 > Reporter: Stefan Seelmann > Assignee: Stefan Seelmann >Priority: Blocker > Fix For: 2.0.0-M18 > > > The artifacts.xml.xz and content.xml.xz files that are generated for the > update site dependencies is wrong, they only contains parts of the > dependencies. This means that the update site doesn't work. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Created] (DIRSTUDIO-1283) Generated update site is broken
Stefan Seelmann created DIRSTUDIO-1283: -- Summary: Generated update site is broken Key: DIRSTUDIO-1283 URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1283 Project: Directory Studio Issue Type: Task Affects Versions: 2.0.0-M17 Reporter: Stefan Seelmann Assignee: Stefan Seelmann Fix For: 2.0.0-M18 The artifacts.xml.xz and content.xml.xz files that are generated for the update site dependencies is wrong, they only contains parts of the dependencies. This means that the update site doesn't work. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[RESULT][VOTE] Apache Directory Studio 2.0.0.v20210717-M17 release
Closing with 3 binding votes from Shawn, Emmanuel and me. On 7/18/21 8:58 AM, Stefan Seelmann wrote: > Hi all, > > this is a vote for the next Studio release. > > This is mainly a bugfix and security enhancement release. The full > release notes are here: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310590=12349721 > > Git tag: > https://gitbox.apache.org/repos/asf?p=directory-studio.git;a=shortlog;h=refs/tags/2.0.0.v20210717-M17 > https://github.com/apache/directory-studio/tree/2.0.0.v20210717-M17 > > Nexus staging repository: > https://repository.apache.org/content/repositories/orgapachedirectory-1204/ > > Distribution packages (source, binary archives and installers, update site): > https://dist.apache.org/repos/dist/dev/directory/studio/2.0.0.v20210717-M17/ > > User guides: > https://nightlies.apache.org/directory/studio/2.0.0.v20210717-M17/userguide/ > > Please cast your vote: > [ ] +1 : Yes, release Apache Directory Studio 2.0.0.v20210717-M17 > [ ] ± 0 : I don't care > [ ] -1 : No, don't release Apache Directory Studio 2.0.0.v20210717-M17 > > Kind Regards, > Stefan > > > - > To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org > For additional commands, e-mail: dev-h...@directory.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
Re: [VOTE] Apache Directory Studio 2.0.0.v20210717-M17 release
On 7/18/21 11:43 PM, Emmanuel Lécharny wrote: > My +1. > > A few remarks: > - your GPG keys does not seem to be trusted (this is when I use the asc > file to check the signature). I typically get: > > $ gpg --verify > ~/Downloads/org.apache.directory.studio.parent-2.0.0.v20210717-M17-source-release.zip.asc > org.apache.directory.studio.parent-2.0.0.v20210717-M17-source-release.zip > gpg: Signature made Sat Jul 17 19:59:37 2021 CEST > gpg: using RSA key 63CE676698B26D3A36D77527223BD93328686142 > gpg: Good signature from "Stefan Seelmann (CODE SIGNING KEY) > " [unknown] > gpg: WARNING: This key is not certified with a trusted signature! > gpg: There is no indication that the signature belongs to the > owner. > Primary key fingerprint: 63CE 6766 98B2 6D3A 36D7 7527 223B D933 2868 6142 > > Not sure that is a big deal. I never attended a key signing party with that key, so it's not in the web-of-trust. And you probably also didn't mark my key as trusted (which you shouldn't do). So based on the KEYS file that you imported only the valid signature can be verified. I think it's plain normal and conform to https://infra.apache.org/release-signing.html. > - The packages are signed using asc, SHA1 and MD5. The two last are > deprecated and should be replaced by SHA 256/512 Hm, but SHA1 and MD5 are only used for the artifacts in the Maven repo, right? The packages at https://dist.apache.org/repos/dist/dev/directory/studio/2.0.0.v20210717-M17/ only use SHA 256 and SHA 512. Is there a way now to also use the stronger hash methods with Maven? - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRSTUDIO-1280) Studio browser connections to replicated LDAP dont work with Mac OS Big Sur
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17382757#comment-17382757 ] Stefan Seelmann commented on DIRSTUDIO-1280: Which LDAP servers do you use? If it's Oracle then likely then it's like the same reason as in DIRSTUDIO-1271. The next Studio release is currently voted on, if you want you can already test it, infos are here: https://lists.apache.org/thread.html/r19666e069490491eb7c58420dde9c8900ac6dbf3eb001f5f1250ba8e%40%3Cdev.directory.apache.org%3E > Studio browser connections to replicated LDAP dont work with Mac OS Big Sur > --- > > Key: DIRSTUDIO-1280 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1280 > Project: Directory Studio > Issue Type: Bug > Components: studio-ldapbrowser >Affects Versions: 2.0.0-M16 > Environment: Mac OS Big Sur 11.2.3 > Mac OS Big Sur 11.4 >Reporter: Sourabh Idoorkar >Priority: Major > > I was using Apache Studio to connect to my LDAP which is setup in a > replicated topology. Mostly the LDAP Browser to view and edit data. This was > working fine. But recently my Mac went through the Big Sur update and since > then the studio browser to a replicated topology is not working. > I see the Root DSE as blank on the LDAP Browser > Reason I think this could be a Studio issue with the Mac Big Sur version > # I have investigated everything possible from my LDAP end and there have > been no recent changes to begin with > # I ended up trying Apache Studio from my Windows laptop and that worked > fine for the same LDAP. No issues with connection or browsing. That was with > M13 version > # I have since tried JXplorer to isolate if maybe its something to do with > MAC to LDAP connection rather than Studio to LDAP. But connections via > JXplorer work fine - view as well as edits > # Re-importing connections to Studio did not work - I thought maybe the > connections have a new format and the old one doesnt work anymore > # I tried it on a friend's laptop which is also MAC but older OS and it > works fine there > # Trying to run an older version M14 in the Mac Big Sur results in - > java.lang.NullPointerException: Cannot invoke > "org.eclipse.swt.internal.cocoa.NSGraphicsContext.graphicsPort()" because > "graphicsContext" is null -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[VOTE] Apache Directory Studio 2.0.0.v20210717-M17 release
Hi all, this is a vote for the next Studio release. This is mainly a bugfix and security enhancement release. The full release notes are here: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310590=12349721 Git tag: https://gitbox.apache.org/repos/asf?p=directory-studio.git;a=shortlog;h=refs/tags/2.0.0.v20210717-M17 https://github.com/apache/directory-studio/tree/2.0.0.v20210717-M17 Nexus staging repository: https://repository.apache.org/content/repositories/orgapachedirectory-1204/ Distribution packages (source, binary archives and installers, update site): https://dist.apache.org/repos/dist/dev/directory/studio/2.0.0.v20210717-M17/ User guides: https://nightlies.apache.org/directory/studio/2.0.0.v20210717-M17/userguide/ Please cast your vote: [ ] +1 : Yes, release Apache Directory Studio 2.0.0.v20210717-M17 [ ] ± 0 : I don't care [ ] -1 : No, don't release Apache Directory Studio 2.0.0.v20210717-M17 Kind Regards, Stefan - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
Re: Upcoming fortress release
On 7/15/21 10:18 PM, Shawn McKinney wrote: > A post-mortem on deploying to new website. > > One correction, I cloned with this: > > git clone https://gitbox.apache.org/repos/asf/directory-site.git > > Instead of using the GitHub url. I suppose one could clone GitHub repo and > add remote origin to gitbox. I normally push to GitHub. That requires to link the GitHub and GitBox accounts: https://gitbox.apache.org/setup/ Kind regards, Stefan - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
Re: [VOTE] Apache Fortress 2.0.6 release (take 2)
+1 Checked the licenses. Checked the signatures and checksums. Built all 4 projects with Java 11. Run the Apache Fortress Core Integration Test against OpenLDAP. Kind Regards, Stefan On 7/11/21 5:49 AM, Emmanuel Lécharny wrote: > Checked the release, > checked the signaturre, > > +1 from me ! > > On 08/07/2021 20:56, Stefan Seelmann wrote: >> FYI, I won't have time before Sunday to check the release. >> >> On 7/6/21 8:57 PM, Shawn McKinney wrote: >>> I have removed (and verified) the jboss jar dependency from fortress >>> rest. The repos are retagged. Artifacts rebuilt and staged once >>> again. Let’s try this again... >>> >>> >>> Hello, >>> >>> This is an announcement to vote for the next release of Apache >>> Directory Fortress, 2.0.6. >>> >>> Here are the list of bugs and enhancements: >>> >>> https://issues.apache.org/jira/projects/FC/versions/12349361 >>> >>> A tag created for git: ‘2.0.6', and the sources may be pulled using >>> git commands: >>> git clone --branch 2.0.6 >>> https://git-wip-us.apache.org/repos/asf/directory-fortress-core.git >>> git clone --branch 2.0.6 >>> https://git-wip-us.apache.org/repos/asf/directory-fortress-realm.git >>> git clone --branch 2.0.6 >>> https://git-wip-us.apache.org/repos/asf/directory-fortress-enmasse.git >>> git clone --branch 2.0.6 >>> https://git-wip-us.apache.org/repos/asf/directory-fortress-commander.git >>> >>> with their associated checksums: >>> - core: 33ac2682170e26272cdc05b370f6c1ffcd834edc >>> - realm: f4777d0842e4a93ad35b4f2ed3d00d9d185728ed >>> - rest: 35a96e40030182a99a4c8cd9effad5ddc0b4bc45 >>> - web: 647356f53fcc9406d434fee8a0d13123dbcde510 >>> >>> Or, source and binary distros may be downloaded from SVN: >>> - https://dist.apache.org/repos/dist/dev/directory/fortress/2.0.6/ >>> >>> The staging repo on Nexus: >>> - >>> https://repository.apache.org/content/repositories/orgapachedirectory-1203 >>> >>> >>> Test against LDAP using one of these: >>> - >>> https://github.com/apache/directory-fortress-core/blob/master/README-QUICKSTART-DOCKER-APACHEDS.md >>> >>> - >>> https://github.com/apache/directory-fortress-core/blob/master/README-QUICKSTART-DOCKER-SLAPD.md >>> >>> >>> - Choose one of the above. Complete (only) the sections leading up >>> to and including the SECTION entitled: 'Apache Fortress Core >>> Integration Test’ >>> >>> Please vote: >>> [ ] +1 | Release Fortress 2.0.6 >>> [ ] +/-0 | Abstain >>> [ ] -1 | Do *NOT* Release Fortress 2.0.6 >>> >>> >>> — >>> Shawn >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org >>> For additional commands, e-mail: dev-h...@directory.apache.org >>> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org >> For additional commands, e-mail: dev-h...@directory.apache.org >> > - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
Re: [VOTE] Apache Fortress 2.0.6 release (take 2)
FYI, I won't have time before Sunday to check the release. On 7/6/21 8:57 PM, Shawn McKinney wrote: > I have removed (and verified) the jboss jar dependency from fortress rest. > The repos are retagged. Artifacts rebuilt and staged once again. Let’s try > this again... > > > Hello, > > This is an announcement to vote for the next release of Apache Directory > Fortress, 2.0.6. > > Here are the list of bugs and enhancements: > > https://issues.apache.org/jira/projects/FC/versions/12349361 > > A tag created for git: ‘2.0.6', and the sources may be pulled using git > commands: > git clone --branch 2.0.6 > https://git-wip-us.apache.org/repos/asf/directory-fortress-core.git > git clone --branch 2.0.6 > https://git-wip-us.apache.org/repos/asf/directory-fortress-realm.git > git clone --branch 2.0.6 > https://git-wip-us.apache.org/repos/asf/directory-fortress-enmasse.git > git clone --branch 2.0.6 > https://git-wip-us.apache.org/repos/asf/directory-fortress-commander.git > > with their associated checksums: > - core: 33ac2682170e26272cdc05b370f6c1ffcd834edc > - realm: f4777d0842e4a93ad35b4f2ed3d00d9d185728ed > - rest: 35a96e40030182a99a4c8cd9effad5ddc0b4bc45 > - web: 647356f53fcc9406d434fee8a0d13123dbcde510 > > Or, source and binary distros may be downloaded from SVN: > - https://dist.apache.org/repos/dist/dev/directory/fortress/2.0.6/ > > The staging repo on Nexus: > - https://repository.apache.org/content/repositories/orgapachedirectory-1203 > > Test against LDAP using one of these: > - > https://github.com/apache/directory-fortress-core/blob/master/README-QUICKSTART-DOCKER-APACHEDS.md > - > https://github.com/apache/directory-fortress-core/blob/master/README-QUICKSTART-DOCKER-SLAPD.md > > - Choose one of the above. Complete (only) the sections leading up to and > including the SECTION entitled: 'Apache Fortress Core Integration Test’ > > Please vote: > [ ] +1 | Release Fortress 2.0.6 > [ ] +/-0 | Abstain > [ ] -1 | Do *NOT* Release Fortress 2.0.6 > > > — > Shawn > - > To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org > For additional commands, e-mail: dev-h...@directory.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
Re: [VOTE] Apache Fortress 2.0.6 release
I found one weird thing: the fortress-rest-2.0.6.war contains in WEB-INF/lib the jboss-rmi-api_1.0_spec-1.0.6.Final.jar. This is either GPL/LGPL licensed, the git repo includes no license file, the pom.xml mentions LGPL [1], the license file within the JAR states GPL+CPE. But this is a transitive dependency from org.apache.cxf:cxf-core:jar:3.4.4, defined in it's parent pom [2], so if they include it as dependency it must be ok, right? It's included in fortress-rest since 2.0.5 and was introduced in CXF 3.3.0 [3] Anyone has a clue? Or should we ask legal? Kind Regards, Stefan [1] https://github.com/jboss/jboss-rmi-api_spec/blob/jboss-rmi-api_1.0_spec-1.0.6.Final/pom.xml [2] https://github.com/apache/cxf/blob/cxf-3.4.4/parent/pom.xml#L2352 [3] https://issues.apache.org/jira/browse/CXF-7741 On 7/4/21 4:13 PM, Shawn McKinney wrote: > Hello, > > This is an announcement to vote for the next release of Apache Directory > Fortress, 2.0.6. > > Here are the list of bugs and enhancements: > > https://issues.apache.org/jira/projects/FC/versions/12349361 > > A tag created for git: ‘2.0.6', and the sources may be pulled using git > commands: > git clone --branch 2.0.6 > https://git-wip-us.apache.org/repos/asf/directory-fortress-core.git > git clone --branch 2.0.6 > https://git-wip-us.apache.org/repos/asf/directory-fortress-realm.git > git clone --branch 2.0.6 > https://git-wip-us.apache.org/repos/asf/directory-fortress-enmasse.git > git clone --branch 2.0.6 > https://git-wip-us.apache.org/repos/asf/directory-fortress-commander.git > > with their associated checksums: > - core: 4562f51a4a05ec4bd52e6c8d737491b0b4d99056 > - realm: 643823206c4934c6a463a2c6e5bbb00defab1435 > - rest: eb7e363dad5ccb9477a6ca85ebc1a83903d18c9d > - web: 306a960af86922f51695efec2f45d1e0fba441c0 > > Or, source and binary distros may be downloaded from SVN: > - https://dist.apache.org/repos/dist/dev/directory/fortress/2.0.6/ > > The staging repo on Nexus: > - https://repository.apache.org/content/repositories/orgapachedirectory-1202 > > Test against LDAP using one of these: > - > https://github.com/apache/directory-fortress-core/blob/master/README-QUICKSTART-DOCKER-APACHEDS.md > - > https://github.com/apache/directory-fortress-core/blob/master/README-QUICKSTART-DOCKER-SLAPD.md > > - Choose one of the above. Complete (only) the sections leading up to and > including the SECTION entitled: 'Apache Fortress Core Integration Test’ > > Please vote: > [ ] +1 | Release Fortress 2.0.6 > [ ] +/-0 | Abstain > [ ] -1 | Do *NOT* Release Fortress 2.0.6 > > — > Shawn > - > To unsubscribe, e-mail: fortress-unsubscr...@directory.apache.org > For additional commands, e-mail: fortress-h...@directory.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
Re: [ STUDIO ] Problem viewing / setting configuration
On 7/4/21 5:48 PM, Shawn McKinney wrote: > Hi, > > Trying to get LDAPS configured on ApacheDS version 2.0.0.AM26 using Studio > version 2.0.0.v20210213-M16. > > This on an Ubuntu20 w/ openjdk version 11.0.11. > > I connect to the server instance and open configuration dialog and get this: > > ELEMENT_FOR_OID_DOES_NOT_EXIST ATTRIBUTE_TYPE for OID ftmodcode does not exist > > Full error[1] listed below. > > When I open the schema browser, I find that the specified attribute type > defined. > > The fortress integration tests have also been run on this instance providing > verification that its schema is valid. > > Any ideas on what this problem is? > > Thanks, > > — > Shawn > > [1] Unable to load the configuration. > - ERR_13735_ELEMENT_FOR_OID_DOES_NOT_EXIST ATTRIBUTE_TYPE for OID ftmodcode > does not exist! > org.apache.directory.api.ldap.model.exception.LdapNoSuchAttributeException: > ERR_13735_ELEMENT_FOR_OID_DOES_NOT_EXIST ATTRIBUTE_TYPE for OID ftmodcode > does not exist! > at > org.apache.directory.api.ldap.model.schema.registries.DefaultAttributeTypeRegistry.lookup(DefaultAttributeTypeRegistry.java:316) > at > org.apache.directory.api.ldap.model.schema.registries.DefaultAttributeTypeRegistry.lookup(DefaultAttributeTypeRegistry.java:50) > at > org.apache.directory.api.ldap.schema.manager.impl.DefaultSchemaManager.lookupAttributeTypeRegistry(DefaultSchemaManager.java:1831) > at > org.apache.directory.api.ldap.model.entry.DefaultEntry.(DefaultEntry.java:320) > at > org.apache.directory.studio.apacheds.configuration.jobs.LoadConfigurationRunnable.readConfiguration(LoadConfigurationRunnable.java:407) This method loads the config from the "ou=config" partition by fetching all entries within this partition. It seems some entry in this partition contains a "ftmodcode" attribute. I think that's not supported, the config reader expects that only ApacheDS config schema elements are used (AT and OC with an "ads-" prefix). How did the ftmodcode attribute get there? Kind Regards, Stefan - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
Re: Errors Deleting Entries within Studio
Hi Dave, On 7/4/21 2:00 AM, David Filip wrote: > Greetings, > > I have noticed that when deleting entries too fast using Apache Directory > Studio Version: 2.0.0.v20210213-M16 (ApacheDS 2.0.0.AM26), I receive the > following error: > > ERR_04169_RESPONSE_QUEUE_EMPTIED The response queue has been emptied, no > response was found > > > > I am not sure if this is a Studio (frontend) or ApacheDS (backend) issue? Can you please give detailed information about your environment? Studio: Which operating system and which Java version do you use? Server: Do you use the ApacheDS embedded in Studio? Otherwise which type of directory server do you use? > To Reproduce: > > Load a large number (200) of entire into the directory via JNDI API. > > After the load completes, select 8 - 10 entries at a time in Studio, hit the > [Delete] key, and confirm deleting those entries. > > If done successively, without waiting a sufficient amount of time, will > generate the above error, and not all of the selected entries will have been > deleted (but usually one or a few have been deleted). Hit F5 to refresh to > determine which entires still remain. > > Expected Result: > > All entires should be successfully deleted without any error or warning > message. > > Work Around: > > Wait 30 - 60 scones between each batch (8 - 10 entires) of deletions. Or > select a smaller set of entries (5 - 6) and wait 15 - 20 seconds between each > batch. > > Has anyone else experienced this? Is this a known limitation? I the previous batch completed before you run the next batch? If a batch is still running it should show up in the "Progress" view [1], and after it finished the "LDAP Browser" view usually is refreshed. In you run a 2nd delete batch while the first one is still running it may be related to the fact that the LDAP API is not really thread safe [2], so if the same connection is used for multiple operations unexpected things may happen. Kind Regards, Stefan [1] https://nightlies.apache.org/directory/studio/2.0.0.v20210213-M16/userguide/ldap_browser/tools_progress_view.html [2] https://issues.apache.org/jira/browse/DIRAPI-237 - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
Re: Too many files with unapproved license: 427 See RAT report
On 6/30/21 10:11 PM, Stefan Seelmann wrote: > On 6/30/21 9:28 PM, Shawn McKinney wrote: >> Hello, >> >> Beginning fortress release preps and stumbled across this when I run: >> >> ``` >> mvn -Papache-release -DdryRun=true release:prepare >> >> INFO] [INFO] BUILD FAILURE >> >> … >> >> [INFO] [ERROR] Failed to execute goal >> org.apache.rat:apache-rat-plugin:0.11:check (default) on project >> fortress-core: Too many files with unapproved license: 427 See RAT report >> in: /home/smckinn/GIT/fortressDev/directory-fortress-core/target/rat.txt >> ``` >> >> When I look at the rat report I see files listed that have apache license >> header included and ones that have never created a problem before. >> >> Does anyone know what’s going on here? > > This has to do with the change of the URL from http:// to https:// in > the license header which the apache-rat plugin 0.13 doesn't understand. > Workaround is to add those 10 lines to the config: > > https://github.com/apache/directory-ldap-api/blob/master/pom.xml#L163:L173 More info here: https://lists.apache.org/thread.html/r2e769cb719a4ce4717352e451cab4fc18529b5e6897f00fda2cedf20%40%3Cdev.directory.apache.org%3E - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
Re: Too many files with unapproved license: 427 See RAT report
On 6/30/21 9:28 PM, Shawn McKinney wrote: > Hello, > > Beginning fortress release preps and stumbled across this when I run: > > ``` > mvn -Papache-release -DdryRun=true release:prepare > > INFO] [INFO] BUILD FAILURE > > … > > [INFO] [ERROR] Failed to execute goal > org.apache.rat:apache-rat-plugin:0.11:check (default) on project > fortress-core: Too many files with unapproved license: 427 See RAT report in: > /home/smckinn/GIT/fortressDev/directory-fortress-core/target/rat.txt > ``` > > When I look at the rat report I see files listed that have apache license > header included and ones that have never created a problem before. > > Does anyone know what’s going on here? This has to do with the change of the URL from http:// to https:// in the license header which the apache-rat plugin 0.13 doesn't understand. Workaround is to add those 10 lines to the config: https://github.com/apache/directory-ldap-api/blob/master/pom.xml#L163:L173 Kind Regards, Stefan - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
Re: Upcoming fortress release
On 6/29/21 9:10 PM, Shawn McKinney wrote: > Soon will be releasing a new fortress based on ldap api 2.x. Nice! > My question, how to update the (new) website with the latest package info, > docs, notes, etc? > > If there’s already a doc or mail with this info I would appreciate a pointer. > > As I recall, (hopefully) it’s just a matter of checking out one git repo, > making changes to the associated project files (in markdown format) and > pushing those changes. Correct, easy peasy lemon squeezy Here is the git repo: https://github.com/apache/directory-site/ Download and run Hugo (see the readme) so you can preview changes locally. There are many files and folders so it may be a bit overwhelming. For the LDAP API and Studio the files that need to be modified for a new release are documented, I hope those pointers help you for Fortress: https://directory.apache.org/api/developer-guide.html#update-the-web-site https://github.com/apache/directory-studio#website Kind Regards, Stefan - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
Apache Directory LDAP API 2.1.0 released
The Apache Directory Team is proud to announce the availability of version 2.1.0 of the Apache Directory LDAP API. The Apache Directory LDAP API is an ongoing effort to provide an enhanced LDAP API, as a replacement for JNDI and the existing LDAP API (jLdap and Mozilla LDAP API). This is a schema aware API, with some convenient ways to access a LDAP server. This API is not only targeting the Apache Directory Server, but should work pristine with any LDAP server. It’s also an extensible API : new Controls, schema elements and network layer could be added or used in the near future. It’s also OSGi capable. This is a security enhancement release. Most notable are support for TLSv1.3 and addition of the SASL integrity and confidentiality layer. Website : https://directory.apache.org/api Download : https://directory.apache.org/api/downloads-2.html User's Guide : http://directory.apache.org/api/user-guide.html - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRSERVER-2350) Database corruption
[
https://issues.apache.org/jira/browse/DIRSERVER-2350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371575#comment-17371575
]
Stefan Seelmann commented on DIRSERVER-2350:
https://directory.apache.org/apacheds/production-readiness.html
> Database corruption
> ---
>
> Key: DIRSERVER-2350
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2350
> Project: Directory ApacheDS
> Issue Type: Bug
>Affects Versions: 2.0.0.AM26
>Reporter: Matt Pavlovich
>Priority: Major
>
> A test-only LDAP server running with a small number of entries appears to
> have become corrupt and will no longer start clean
> {noformat}
> [09:28:54] WARN [org.apache.directory.api.ldap.model.entry.Value] -
> MSG_13202_AT_IS_NULL ()
> [09:28:54] WARN [org.apache.directory.api.ldap.model.entry.Value] -
> MSG_13202_AT_IS_NULL ()
> [09:28:54] ERROR [org.apache.directory.server.UberjarMain] - Failed to start
> the service.
> org.apache.directory.api.ldap.model.exception.LdapOtherException
> at
> org.apache.directory.server.core.api.partition.AbstractPartition.initialize(AbstractPartition.java:91)
> at
> org.apache.directory.server.core.DefaultDirectoryService.initialize(DefaultDirectoryService.java:1986)
> at
> org.apache.directory.server.core.DefaultDirectoryService.startup(DefaultDirectoryService.java:1244)
> at
> org.apache.directory.server.ApacheDsService.initDirectoryService(ApacheDsService.java:390)
> at
> org.apache.directory.server.ApacheDsService.start(ApacheDsService.java:205)
> at
> org.apache.directory.server.ApacheDsService.start(ApacheDsService.java:152)
> at org.apache.directory.server.UberjarMain.start(UberjarMain.java:153)
> at org.apache.directory.server.UberjarMain.main(UberjarMain.java:80)
> Caused by: org.apache.directory.api.ldap.model.exception.LdapOtherException
> at
> org.apache.directory.server.core.api.partition.AbstractPartition.initialize(AbstractPartition.java:91)
> at
> org.apache.directory.server.core.shared.partition.DefaultPartitionNexus.addContextPartition(DefaultPartitionNexus.java:834)
> at
> org.apache.directory.server.core.shared.partition.DefaultPartitionNexus.doInit(DefaultPartitionNexus.java:242)
> at
> org.apache.directory.server.core.api.partition.AbstractPartition.initialize(AbstractPartition.java:86)
> ... 7 more
> Caused by: org.apache.directory.api.ldap.model.exception.LdapOtherException
> at
> org.apache.directory.server.core.partition.impl.btree.jdbm.JdbmPartition.convertAndInit(JdbmPartition.java:835)
> at
> org.apache.directory.server.core.partition.impl.btree.AbstractBTreePartition.setupSystemIndices(AbstractBTreePartition.java:437)
> at
> org.apache.directory.server.core.partition.impl.btree.AbstractBTreePartition.doInit(AbstractBTreePartition.java:629)
> at
> org.apache.directory.server.core.partition.impl.btree.jdbm.JdbmPartition.doInit(JdbmPartition.java:511)
> at
> org.apache.directory.server.core.api.partition.AbstractPartition.initialize(AbstractPartition.java:86)
> ... 10 more
> Caused by: java.io.EOFException
> at
> java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2797)
> at
> java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:3272)
> at
> java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:932)
> at java.io.ObjectInputStream.(ObjectInputStream.java:394)
> at jdbm.helper.Serialization.deserialize(Serialization.java:93)
> at jdbm.helper.DefaultSerializer.deserialize(DefaultSerializer.java:95)
> at jdbm.recman.BaseRecordManager.fetch(BaseRecordManager.java:329)
> at jdbm.recman.CacheRecordManager.fetch(CacheRecordManager.java:264)
> at jdbm.recman.CacheRecordManager.fetch(CacheRecordManager.java:243)
> at jdbm.btree.BTree.load(BTree.java:248)
> at
> org.apache.directory.server.core.partition.impl.btree.jdbm.JdbmTable.(JdbmTable.java:150)
> at
> org.apache.directory.server.core.partition.impl.btree.jdbm.JdbmIndex.initTables(JdbmIndex.java:209)
> at
> org.apache.directory.server.core.partition.impl.btree.jdbm.JdbmIndex.init(JdbmIndex.java:166)
> at
> org.apache.directory.server.core.partition.impl.btree.jdbm.JdbmPartition.convertAndInit(JdbmPartition.java:831)
> ... 14 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[RESULT][VOTE] Release Apache LDAP API 2.1.0
I'm closing this vote, with 4 binding +1 votes from Shawn, Emmanuel, Colm, and myself. Kind Regards, Stefan On 6/25/21 8:02 PM, Stefan Seelmann wrote: > Hi all, > > this is a vote for the release of the Apache LDAP API 2.1.0. > > This is a feature release. Most notable are support for TLSv1.3 and > addition of the SASL integrity and confidentiality layer. All changes > are listed here: > https://issues.apache.org/jira/projects/DIRAPI/versions/12350235 > > The git tag: > https://gitbox.apache.org/repos/asf?p=directory-ldap-api.git;a=tag;h=refs/tags/2.1.0 > https://github.com/apache/directory-ldap-api/tree/2.1.0 > > The source and binary distribution packages: > https://dist.apache.org/repos/dist/dev/directory/api/dist/2.1.0/ > > The staging repository: > https://repository.apache.org/content/repositories/orgapachedirectory-1197/ > > Please cast your votes: > [ ] +1 Release Apache LDAP API 2.1.0 > [ ] 0 abstain > [ ] -1 Do not release Apache LDAP API 2.1.0 > > Kind Regards, > Stefan > > - > To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org > For additional commands, e-mail: dev-h...@directory.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[VOTE] Release Apache LDAP API 2.1.0
Hi all, this is a vote for the release of the Apache LDAP API 2.1.0. This is a feature release. Most notable are support for TLSv1.3 and addition of the SASL integrity and confidentiality layer. All changes are listed here: https://issues.apache.org/jira/projects/DIRAPI/versions/12350235 The git tag: https://gitbox.apache.org/repos/asf?p=directory-ldap-api.git;a=tag;h=refs/tags/2.1.0 https://github.com/apache/directory-ldap-api/tree/2.1.0 The source and binary distribution packages: https://dist.apache.org/repos/dist/dev/directory/api/dist/2.1.0/ The staging repository: https://repository.apache.org/content/repositories/orgapachedirectory-1197/ Please cast your votes: [ ] +1 Release Apache LDAP API 2.1.0 [ ] 0 abstain [ ] -1 Do not release Apache LDAP API 2.1.0 Kind Regards, Stefan - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Resolved] (DIRAPI-377) Add LDAP Relax Rules Control
[ https://issues.apache.org/jira/browse/DIRAPI-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann resolved DIRAPI-377. Resolution: Fixed https://github.com/apache/directory-ldap-api/commit/12353c1487412b0c7e0d36a68297ab713dd0 > Add LDAP Relax Rules Control > > > Key: DIRAPI-377 > URL: https://issues.apache.org/jira/browse/DIRAPI-377 > Project: Directory Client API > Issue Type: Improvement > Reporter: Stefan Seelmann >Assignee: Shawn McKinney >Priority: Minor > Fix For: 2.1.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Created] (DIRAPI-377) Add LDAP Relax Rules Control
Stefan Seelmann created DIRAPI-377: -- Summary: Add LDAP Relax Rules Control Key: DIRAPI-377 URL: https://issues.apache.org/jira/browse/DIRAPI-377 Project: Directory Client API Issue Type: Improvement Reporter: Stefan Seelmann Assignee: Shawn McKinney Fix For: 2.1.0 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Resolved] (DIRAPI-376) Change getRootDse() to return all user and operational attibutes
[ https://issues.apache.org/jira/browse/DIRAPI-376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann resolved DIRAPI-376. Resolution: Fixed > Change getRootDse() to return all user and operational attibutes > > > Key: DIRAPI-376 > URL: https://issues.apache.org/jira/browse/DIRAPI-376 > Project: Directory Client API > Issue Type: Improvement >Affects Versions: 2.0.2 > Reporter: Stefan Seelmann >Priority: Major > Fix For: 2.0.3 > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRAPI-376) Change getRootDse() to return all user and operational attibutes
[ https://issues.apache.org/jira/browse/DIRAPI-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17368413#comment-17368413 ] Stefan Seelmann commented on DIRAPI-376: https://github.com/apache/directory-ldap-api/commit/06d26e840ee316b5f510ab48019c6390ec972747 > Change getRootDse() to return all user and operational attibutes > > > Key: DIRAPI-376 > URL: https://issues.apache.org/jira/browse/DIRAPI-376 > Project: Directory Client API > Issue Type: Improvement >Affects Versions: 2.0.2 > Reporter: Stefan Seelmann >Priority: Major > Fix For: 2.0.3 > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Updated] (DIRAPI-376) Change getRootDse() to return all user and operational attibutes
[ https://issues.apache.org/jira/browse/DIRAPI-376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann updated DIRAPI-376: --- Component/s: (was: ldap) Fix Version/s: (was: 2.0.3) 2.0.3 Key: DIRAPI-376 (was: DIRSERVER-2349) Affects Version/s: (was: 2.0.2) 2.0.2 Project: Directory Client API (was: Directory ApacheDS) > Change getRootDse() to return all user and operational attibutes > > > Key: DIRAPI-376 > URL: https://issues.apache.org/jira/browse/DIRAPI-376 > Project: Directory Client API > Issue Type: Improvement >Affects Versions: 2.0.2 > Reporter: Stefan Seelmann >Priority: Major > Fix For: 2.0.3 > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Created] (DIRSERVER-2349) Change getRootDse() to return all user and operational attibutes
Stefan Seelmann created DIRSERVER-2349: -- Summary: Change getRootDse() to return all user and operational attibutes Key: DIRSERVER-2349 URL: https://issues.apache.org/jira/browse/DIRSERVER-2349 Project: Directory ApacheDS Issue Type: Improvement Components: ldap Affects Versions: 2.0.2 Reporter: Stefan Seelmann Fix For: 2.0.3 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Updated] (DIRSTUDIO-1279) Show SSL/TLS connection info and certificates
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann updated DIRSTUDIO-1279: --- Description: Add a button to view the used protcol, cipher suite, and the certificate chain for a connection if SSL or StartTLS is configured. (was: Add a button to view the certificate chain for a connection if SSL or StartTLS is configured.) Summary: Show SSL/TLS connection info and certificates (was: Show connection certificate) > Show SSL/TLS connection info and certificates > - > > Key: DIRSTUDIO-1279 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1279 > Project: Directory Studio > Issue Type: Improvement > Components: studio-ldapbrowser >Affects Versions: 2.0.0-M16 > Reporter: Stefan Seelmann >Assignee: Stefan Seelmann >Priority: Major > Fix For: 2.0.0-M17 > > > Add a button to view the used protcol, cipher suite, and the certificate > chain for a connection if SSL or StartTLS is configured. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRSTUDIO-1279) Show SSL/TLS connection info and certificates
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17367007#comment-17367007 ] Stefan Seelmann commented on DIRSTUDIO-1279: https://github.com/apache/directory-studio/commit/3712a950b9f33664bbd70f19e97d5cbc7e6d0022 > Show SSL/TLS connection info and certificates > - > > Key: DIRSTUDIO-1279 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1279 > Project: Directory Studio > Issue Type: Improvement > Components: studio-ldapbrowser >Affects Versions: 2.0.0-M16 > Reporter: Stefan Seelmann >Assignee: Stefan Seelmann >Priority: Major > Fix For: 2.0.0-M17 > > > Add a button to view the used protcol, cipher suite, and the certificate > chain for a connection if SSL or StartTLS is configured. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Resolved] (DIRSTUDIO-1011) ApacheStudio sends SSLv2 Client Hello
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seelmann resolved DIRSTUDIO-1011.
Resolution: Done
Tested with a current Java 11.0.11 and 17-ea, Studio sends either TLSv1.2 or
TLSv1.3.
I assume it was caused by usage of older Java versions.
> ApacheStudio sends SSLv2 Client Hello
> -
>
> Key: DIRSTUDIO-1011
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1011
> Project: Directory Studio
> Issue Type: Bug
>Affects Versions: 2.0.0-M8 (2.0.0.v20130628)
>Reporter: Roy Wellington
>Priority: Major
>
> I'm attempting to configure TLS on a ApacheDS server. I've checked the boxes
> indicated by the docs; attempting to connect over either StartTLS or LDAPS
> both result in "SSL handshake failed."
> Tracing the conversation in Wireshark shows that ApacheDS is sending an SSLv2
> (!) Client Hello, which the server responds to with a TLSv1.0 "Unexpected
> Message" (which is correct). ApacheDS should not be sending an SSLv2 Client
> Hello; instead, it should use the most recent version of TLS. (SSLv2, and
> SSLv3, are broken, and insecure.)
> Simply running,
> {noformat}
> % ldapsearch -H ldaps://:10636
> {noformat}
> …gets me further in the conversation. (Although {{ldapsearch}} complains
> about a bad certificate, but that's because the cert is self-signed;
> Wireshark shows that it _is_ getting further in the SSL conversation (it is
> getting a Server Hello back) than ApacheDS.)
> Note: I'm connecting to an ApacheDS server running on a linux VM, through an
> SSH tunnel; I've edited /etc/hosts so that the DNS name still points to the
> right spot. This should not matter, and I can still connect with openssl (to
> the LDAPS side; obviously openssl is not capable of StartTLS).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Resolved] (DIRAPI-375) Add TLSv1.3 to default protocols
[ https://issues.apache.org/jira/browse/DIRAPI-375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann resolved DIRAPI-375. Resolution: Fixed https://github.com/apache/directory-ldap-api/commit/4322886f8ed9fe0d2c588f0c557e92e4d160149f > Add TLSv1.3 to default protocols > > > Key: DIRAPI-375 > URL: https://issues.apache.org/jira/browse/DIRAPI-375 > Project: Directory Client API > Issue Type: Improvement > Reporter: Stefan Seelmann >Priority: Major > Fix For: 2.0.3 > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Created] (DIRAPI-375) Add TLSv1.3 to default protocols
Stefan Seelmann created DIRAPI-375: -- Summary: Add TLSv1.3 to default protocols Key: DIRAPI-375 URL: https://issues.apache.org/jira/browse/DIRAPI-375 Project: Directory Client API Issue Type: Improvement Reporter: Stefan Seelmann Fix For: 2.0.3 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Resolved] (DIRSTUDIO-761) GSSAPI Authentication fails when using ADS LDAP Client API
[ https://issues.apache.org/jira/browse/DIRSTUDIO-761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann resolved DIRSTUDIO-761. --- Resolution: Fixed This has been fixed in scope of the linked issues and tests have been added. > GSSAPI Authentication fails when using ADS LDAP Client API > -- > > Key: DIRSTUDIO-761 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-761 > Project: Directory Studio > Issue Type: Bug > Components: studio-connection >Affects Versions: 2.0.0-M1 (2.0.0.v20120111) > Environment: Debian Wheezy >Reporter: Bill MacAllister >Priority: Minor > Fix For: 2.0.0-M17 > > > GSSAPI connections to an OpenLDAP server fail when using ADS LDAP Client API > with the following error message: > Error while opening connection > - Missing schema location in RootDSE, using default schema. > Missing schema location in RootDSE, using default schema. > The connection succeeds when the connection is changed to use JNDI. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRSTUDIO-1219) Directory Studio doesn't StartTLS before authenticating
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17366162#comment-17366162
]
Stefan Seelmann commented on DIRSTUDIO-1219:
Changed usage of {{useTls}} flag in the LDAP API:
https://issues.apache.org/jira/browse/DIRAPI-374
https://github.com/apache/directory-ldap-api/commit/bf32f0e902ffb08839defcaf3c1de5164d83e092
Call {{startTls()}} always after connect, verify that the connection is
secured. Also add various tests where the server requries confidentiality:
https://github.com/apache/directory-studio/commit/b53667ab3b87afcfcd6f1b1df90d733636cfc888
> Directory Studio doesn't StartTLS before authenticating
> ---
>
> Key: DIRSTUDIO-1219
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1219
> Project: Directory Studio
> Issue Type: Bug
> Components: studio-connection
>Affects Versions: 2.0.0-M16
> Environment: Apache Directory Studio is running on Mac OS 10.14 with
> jdk1.8.0_201.
>Reporter: Hugh Cole-Baker
>Assignee: Stefan Seelmann
>Priority: Blocker
> Fix For: 2.0.0-M17
>
>
> There is an issue connecting to an OpenLDAP server configured with
> olcSaslSecProps: noplain,noanonymous,minssf=1
> i.e. The server requires some form of transport encryption. I have chosen
> StartTLS and SASL GSSAPI authentication, but Directory Studio doesn't
> actually do StartTLS before binding - I can see this by looking at the
> network traffic using Wireshark. I would have expected it to start TLS before
> attempting to bind.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Resolved] (DIRSTUDIO-1219) Directory Studio doesn't StartTLS before authenticating
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann resolved DIRSTUDIO-1219. Resolution: Fixed > Directory Studio doesn't StartTLS before authenticating > --- > > Key: DIRSTUDIO-1219 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1219 > Project: Directory Studio > Issue Type: Bug > Components: studio-connection >Affects Versions: 2.0.0-M16 > Environment: Apache Directory Studio is running on Mac OS 10.14 with > jdk1.8.0_201. >Reporter: Hugh Cole-Baker >Assignee: Stefan Seelmann >Priority: Blocker > Fix For: 2.0.0-M17 > > > There is an issue connecting to an OpenLDAP server configured with > olcSaslSecProps: noplain,noanonymous,minssf=1 > i.e. The server requires some form of transport encryption. I have chosen > StartTLS and SASL GSSAPI authentication, but Directory Studio doesn't > actually do StartTLS before binding - I can see this by looking at the > network traffic using Wireshark. I would have expected it to start TLS before > attempting to bind. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRSTUDIO-1220) Directory Studio doesn't use the SASL confidentiality layer after negotiating its use
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17366138#comment-17366138 ] Stefan Seelmann commented on DIRSTUDIO-1220: Implemented SASL security layer in the LDAP API https://issues.apache.org/jira/browse/DIRAPI-373: https://github.com/apache/directory-ldap-api/commit/2cf66a14c58d4c0ddd3dd3700566a4e72cdb3518 Use that LDAP API version and added tests: https://github.com/apache/directory-studio/commit/18ad16e89deb2998ee0fef0f16a9a85a0df1ddd2 > Directory Studio doesn't use the SASL confidentiality layer after negotiating > its use > - > > Key: DIRSTUDIO-1220 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1220 > Project: Directory Studio > Issue Type: Bug > Components: studio-connection > Environment: Apache Directory Studio is running on Mac OS 10.14 with > jdk1.8.0_201. >Reporter: Hugh Cole-Baker >Priority: Major > Fix For: 2.0.0-M17 > > > There is an issue connecting to an OpenLDAP server configured with > olcSaslSecProps: noplain,noanonymous,minssf=1 > i.e. The server requires some form of transport encryption. Having a > different issue with StartTLS (DIRSTUDIO-1219), I tried relying on the SASL > confidentiality layer that SASL's GSSAPI mechanism can provide, to meet the > requirement for encryption. I have chosen "No encryption" i.e. no SSL or > StartTLS, in the Network Parameters, and then GSSAPI authentication method > and Quality of Protection: Authentication with integrity and privacy > protection in the SASL settings. > When connecting to the server, what I can see happening when looking at the > network traffic with Wireshark is: > # Client obtains a Kerberos service ticket for the LDAP server and passes it > in the bind request for SASL GSSAPI authentication > # Server replies with a bind response, continuing SASL GSSAPI > authentication, result code 14 (SASL bind in progress), with a 4 byte message > wrapped using GSS_Wrap. The 4 bytes are 0x06 0x01 0x00 0x00 - referring to > RFC4752, the first byte indicates the server supports "Integrity protection" > and/or "Confidentiality protection" but not "No security layer", as expected. > # Client replies with a bind request, continuing SASL GSSAPI authentication, > with a 4 byte message wrapped using GSS_Wrap. The 4 bytes are 0x04 0x01 0x00 > 0x00 - again referring to RFC4752, the first byte indicates the client has > selected "Confidentiality protection". > # Server replies with a bind response with result code 0 (success). > # Client sends a search request with base DN: "", scope: base, filter: > (objectClass=*), for attributes: subschemaSubentry, **with no confidentiality > protection**. This is the point where the client violates the protocol > described in RFC4752 - after negotiating confidentiality protection, the > client needs to actually use it! > # Server interprets the lack of confidentiality protection as an error and > immediately drops the connection (this makes sense from the server's POV as > it could indicate an attempted man-in-the-middle attack) > # Client immediately re-connects to the server, **doesn't bother to bind at > all** and then issues more search requests on the base object, cn=Subschema, > etc. > # An error message appears in Directory Studio "Error while opening > connection > - Missing schema location in RootDSE, using default schema" - this is > presumably because the connection isn't bound, and the server limits what it > will disclose to un-bound clients. > # Directory Studio can't browse the directory at all because it's not > properly bound. > As you can see, there's possibly two issues here - definitely an issue with > the SASL GSSAPI mechanism, and possibly also an issue with the reconnect > logic. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Resolved] (DIRSTUDIO-1220) Directory Studio doesn't use the SASL confidentiality layer after negotiating its use
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann resolved DIRSTUDIO-1220. Assignee: Stefan Seelmann Resolution: Fixed > Directory Studio doesn't use the SASL confidentiality layer after negotiating > its use > - > > Key: DIRSTUDIO-1220 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1220 > Project: Directory Studio > Issue Type: Bug > Components: studio-connection > Environment: Apache Directory Studio is running on Mac OS 10.14 with > jdk1.8.0_201. >Reporter: Hugh Cole-Baker >Assignee: Stefan Seelmann >Priority: Major > Fix For: 2.0.0-M17 > > > There is an issue connecting to an OpenLDAP server configured with > olcSaslSecProps: noplain,noanonymous,minssf=1 > i.e. The server requires some form of transport encryption. Having a > different issue with StartTLS (DIRSTUDIO-1219), I tried relying on the SASL > confidentiality layer that SASL's GSSAPI mechanism can provide, to meet the > requirement for encryption. I have chosen "No encryption" i.e. no SSL or > StartTLS, in the Network Parameters, and then GSSAPI authentication method > and Quality of Protection: Authentication with integrity and privacy > protection in the SASL settings. > When connecting to the server, what I can see happening when looking at the > network traffic with Wireshark is: > # Client obtains a Kerberos service ticket for the LDAP server and passes it > in the bind request for SASL GSSAPI authentication > # Server replies with a bind response, continuing SASL GSSAPI > authentication, result code 14 (SASL bind in progress), with a 4 byte message > wrapped using GSS_Wrap. The 4 bytes are 0x06 0x01 0x00 0x00 - referring to > RFC4752, the first byte indicates the server supports "Integrity protection" > and/or "Confidentiality protection" but not "No security layer", as expected. > # Client replies with a bind request, continuing SASL GSSAPI authentication, > with a 4 byte message wrapped using GSS_Wrap. The 4 bytes are 0x04 0x01 0x00 > 0x00 - again referring to RFC4752, the first byte indicates the client has > selected "Confidentiality protection". > # Server replies with a bind response with result code 0 (success). > # Client sends a search request with base DN: "", scope: base, filter: > (objectClass=*), for attributes: subschemaSubentry, **with no confidentiality > protection**. This is the point where the client violates the protocol > described in RFC4752 - after negotiating confidentiality protection, the > client needs to actually use it! > # Server interprets the lack of confidentiality protection as an error and > immediately drops the connection (this makes sense from the server's POV as > it could indicate an attempted man-in-the-middle attack) > # Client immediately re-connects to the server, **doesn't bother to bind at > all** and then issues more search requests on the base object, cn=Subschema, > etc. > # An error message appears in Directory Studio "Error while opening > connection > - Missing schema location in RootDSE, using default schema" - this is > presumably because the connection isn't bound, and the server limits what it > will disclose to un-bound clients. > # Directory Studio can't browse the directory at all because it's not > properly bound. > As you can see, there's possibly two issues here - definitely an issue with > the SASL GSSAPI mechanism, and possibly also an issue with the reconnect > logic. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Resolved] (DIRSERVER-1670) DIGEST-MD5 authentication mechanism must support encryption
[ https://issues.apache.org/jira/browse/DIRSERVER-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann resolved DIRSERVER-1670. Fix Version/s: (was: 2.0.0-RC1) 2.0.0.AM27 Resolution: Fixed Fixed in https://issues.apache.org/jira/browse/DIRSERVER-1632 > DIGEST-MD5 authentication mechanism must support encryption > --- > > Key: DIRSERVER-1670 > URL: https://issues.apache.org/jira/browse/DIRSERVER-1670 > Project: Directory ApacheDS > Issue Type: Bug > Components: authn >Affects Versions: 1.5.7 > Environment: all >Reporter: Hendy Irawan >Priority: Major > Fix For: 2.0.0.AM27 > > > While DIGEST-MD5 should work, encryption doesn't work currently. > A workaround is to disable data security at the client side: > ldapsearch -O "maxssf=0" ... > However, this doesn't work for all clients. (e.g. Thunderbird) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Resolved] (DIRSERVER-1632) Setting SASL QoP to 'auth-int' or 'auth-conf' while connecting using the LDAP API fails and throws a decoder exception
[ https://issues.apache.org/jira/browse/DIRSERVER-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann resolved DIRSERVER-1632. Resolution: Fixed > Setting SASL QoP to 'auth-int' or 'auth-conf' while connecting using the LDAP > API fails and throws a decoder exception > -- > > Key: DIRSERVER-1632 > URL: https://issues.apache.org/jira/browse/DIRSERVER-1632 > Project: Directory ApacheDS > Issue Type: Bug > Components: authn >Affects Versions: 2.0.0-M1 >Reporter: Pierre-Arnaud Marcelot >Priority: Critical > Fix For: 2.0.0.AM27 > > > Setting SASL QoP to 'auth-int' or 'auth-conf' while connecting using the LDAP > API fails and throws a decoder exception. > This only happens when we use the Apache LDAP API to connect to the server. > It works fine using JNDI (with Studio for example). > Two test cases have been added to the > org.apache.directory.server.operations.bind.SaslBindIT class: > - testSaslDigestMd5BindSaslQoPAuthInt() > - testSaslDigestMd5BindSaslQoPAuthConf() > These two tests have been ignored at the moment to avoid build breakage. > Here's the complete stacktrace: > # > org.apache.mina.filter.codec.ProtocolDecoderException: > org.apache.directory.shared.ldap.codec.api.ResponseCarryingException: > ERR_1_BAD_TRANSITION_FROM_STATE Bad transition from state START_STATE, > tag 0x00 (Hexdump: 30 36 02 01 02 61 31 0A 01 00 04 00 04 00 87 28 72 73 70 > 61 75 74 68 3D 63 34 31 63 34 35 65 34 37 31 39 63 33 62 66 37 63 38 63 63 39 > 37 61 64 33 66 32 66 61 37 39 34 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[jira] [Commented] (DIRSERVER-1632) Setting SASL QoP to 'auth-int' or 'auth-conf' while connecting using the LDAP API fails and throws a decoder exception
[ https://issues.apache.org/jira/browse/DIRSERVER-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17366127#comment-17366127 ] Stefan Seelmann commented on DIRSERVER-1632: Added additional tests using openldap cmdline tools: https://github.com/apache/directory-server/commit/77a842e7442936903141ad031eeabdd7ffb0573f > Setting SASL QoP to 'auth-int' or 'auth-conf' while connecting using the LDAP > API fails and throws a decoder exception > -- > > Key: DIRSERVER-1632 > URL: https://issues.apache.org/jira/browse/DIRSERVER-1632 > Project: Directory ApacheDS > Issue Type: Bug > Components: authn >Affects Versions: 2.0.0-M1 >Reporter: Pierre-Arnaud Marcelot >Priority: Critical > Fix For: 2.0.0.AM27 > > > Setting SASL QoP to 'auth-int' or 'auth-conf' while connecting using the LDAP > API fails and throws a decoder exception. > This only happens when we use the Apache LDAP API to connect to the server. > It works fine using JNDI (with Studio for example). > Two test cases have been added to the > org.apache.directory.server.operations.bind.SaslBindIT class: > - testSaslDigestMd5BindSaslQoPAuthInt() > - testSaslDigestMd5BindSaslQoPAuthConf() > These two tests have been ignored at the moment to avoid build breakage. > Here's the complete stacktrace: > # > org.apache.mina.filter.codec.ProtocolDecoderException: > org.apache.directory.shared.ldap.codec.api.ResponseCarryingException: > ERR_1_BAD_TRANSITION_FROM_STATE Bad transition from state START_STATE, > tag 0x00 (Hexdump: 30 36 02 01 02 61 31 0A 01 00 04 00 04 00 87 28 72 73 70 > 61 75 74 68 3D 63 34 31 63 34 35 65 34 37 31 39 63 33 62 66 37 63 38 63 63 39 > 37 61 64 33 66 32 66 61 37 39 34 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[jira] [Commented] (DIRSERVER-1632) Setting SASL QoP to 'auth-int' or 'auth-conf' while connecting using the LDAP API fails and throws a decoder exception
[ https://issues.apache.org/jira/browse/DIRSERVER-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17366109#comment-17366109 ] Stefan Seelmann commented on DIRSERVER-1632: https://github.com/apache/directory-server/commit/e71b7260dcdddf8611701384cfe0559c53ec03a5 > Setting SASL QoP to 'auth-int' or 'auth-conf' while connecting using the LDAP > API fails and throws a decoder exception > -- > > Key: DIRSERVER-1632 > URL: https://issues.apache.org/jira/browse/DIRSERVER-1632 > Project: Directory ApacheDS > Issue Type: Bug > Components: authn >Affects Versions: 2.0.0-M1 >Reporter: Pierre-Arnaud Marcelot >Priority: Critical > Fix For: 2.0.0.AM27 > > > Setting SASL QoP to 'auth-int' or 'auth-conf' while connecting using the LDAP > API fails and throws a decoder exception. > This only happens when we use the Apache LDAP API to connect to the server. > It works fine using JNDI (with Studio for example). > Two test cases have been added to the > org.apache.directory.server.operations.bind.SaslBindIT class: > - testSaslDigestMd5BindSaslQoPAuthInt() > - testSaslDigestMd5BindSaslQoPAuthConf() > These two tests have been ignored at the moment to avoid build breakage. > Here's the complete stacktrace: > # > org.apache.mina.filter.codec.ProtocolDecoderException: > org.apache.directory.shared.ldap.codec.api.ResponseCarryingException: > ERR_1_BAD_TRANSITION_FROM_STATE Bad transition from state START_STATE, > tag 0x00 (Hexdump: 30 36 02 01 02 61 31 0A 01 00 04 00 04 00 87 28 72 73 70 > 61 75 74 68 3D 63 34 31 63 34 35 65 34 37 31 39 63 33 62 66 37 63 38 63 63 39 > 37 61 64 33 66 32 66 61 37 39 34 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00
[jira] [Updated] (DIRSERVER-1632) Setting SASL QoP to 'auth-int' or 'auth-conf' while connecting using the LDAP API fails and throws a decoder exception
[ https://issues.apache.org/jira/browse/DIRSERVER-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann updated DIRSERVER-1632: --- Fix Version/s: (was: 2.0.0-RC1) 2.0.0.AM27 > Setting SASL QoP to 'auth-int' or 'auth-conf' while connecting using the LDAP > API fails and throws a decoder exception > -- > > Key: DIRSERVER-1632 > URL: https://issues.apache.org/jira/browse/DIRSERVER-1632 > Project: Directory ApacheDS > Issue Type: Bug > Components: authn >Affects Versions: 2.0.0-M1 >Reporter: Pierre-Arnaud Marcelot >Priority: Critical > Fix For: 2.0.0.AM27 > > > Setting SASL QoP to 'auth-int' or 'auth-conf' while connecting using the LDAP > API fails and throws a decoder exception. > This only happens when we use the Apache LDAP API to connect to the server. > It works fine using JNDI (with Studio for example). > Two test cases have been added to the > org.apache.directory.server.operations.bind.SaslBindIT class: > - testSaslDigestMd5BindSaslQoPAuthInt() > - testSaslDigestMd5BindSaslQoPAuthConf() > These two tests have been ignored at the moment to avoid build breakage. > Here's the complete stacktrace: > # > org.apache.mina.filter.codec.ProtocolDecoderException: > org.apache.directory.shared.ldap.codec.api.ResponseCarryingException: > ERR_1_BAD_TRANSITION_FROM_STATE Bad transition from state START_STATE, > tag 0x00 (Hexdump: 30 36 02 01 02 61 31 0A 01 00 04 00 04 00 87 28 72 73 70 > 61 75 74 68 3D 63 34 31 63 34 35 65 34 37 31 39 63 33 62 66 37 63 38 63 63 39 > 37 61 64 33 66 32 66 61 37 39 34 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00
[jira] [Resolved] (DIRAPI-373) Implement SASL integrity and confidentiality layer
[ https://issues.apache.org/jira/browse/DIRAPI-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann resolved DIRAPI-373. Resolution: Fixed > Implement SASL integrity and confidentiality layer > -- > > Key: DIRAPI-373 > URL: https://issues.apache.org/jira/browse/DIRAPI-373 > Project: Directory Client API > Issue Type: Improvement >Affects Versions: 2.0.2 > Reporter: Stefan Seelmann > Assignee: Stefan Seelmann >Priority: Major > Fix For: 2.0.3 > > > The LDAP API currently only implements SASL authentication, the security > layer with integrity and confidentiality is not implemented. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Resolved] (DIRAPI-374) Consistify LdapConnectionConfig useTls and useSsl flags
[
https://issues.apache.org/jira/browse/DIRAPI-374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seelmann resolved DIRAPI-374.
Resolution: Fixed
> Consistify LdapConnectionConfig useTls and useSsl flags
> ---
>
> Key: DIRAPI-374
> URL: https://issues.apache.org/jira/browse/DIRAPI-374
> Project: Directory Client API
> Issue Type: Improvement
>Affects Versions: 2.0.2
> Reporter: Stefan Seelmann
> Assignee: Stefan Seelmann
>Priority: Major
> Fix For: 2.0.3
>
>
> The {{LdapConnectionConfig}} class contains two flags {{useSsl}} and
> {{useTls}}. If {{useSsl}} is true the {{SslFilter}} added to the filter chain
> during {{connect()}} and the secure layer is automatically established. If
> {{useTls}} is true that's not the case, the {{SslFilter}} is only added when
> calling {{startTls()}} explicitly or if a simple or anonymous bind is
> performed, but for example not if a SASL bind is performed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRAPI-374) Consistify LdapConnectionConfig useTls and useSsl flags
[
https://issues.apache.org/jira/browse/DIRAPI-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17366017#comment-17366017
]
Stefan Seelmann commented on DIRAPI-374:
https://github.com/apache/directory-ldap-api/commit/bf32f0e902ffb08839defcaf3c1de5164d83e092
> Consistify LdapConnectionConfig useTls and useSsl flags
> ---
>
> Key: DIRAPI-374
> URL: https://issues.apache.org/jira/browse/DIRAPI-374
> Project: Directory Client API
> Issue Type: Improvement
>Affects Versions: 2.0.2
> Reporter: Stefan Seelmann
> Assignee: Stefan Seelmann
>Priority: Major
> Fix For: 2.0.3
>
>
> The {{LdapConnectionConfig}} class contains two flags {{useSsl}} and
> {{useTls}}. If {{useSsl}} is true the {{SslFilter}} added to the filter chain
> during {{connect()}} and the secure layer is automatically established. If
> {{useTls}} is true that's not the case, the {{SslFilter}} is only added when
> calling {{startTls()}} explicitly or if a simple or anonymous bind is
> performed, but for example not if a SASL bind is performed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
Re: [directory-ldap-api] branch master updated: Fixed root DSE access (abandon requests after wrong handling of search cursor)
Hi Radovan,
was this change in getRootDse() on purpose?
I noticed it because of a test failure in the server's test [1] when I
switch the API version to 2.0.3-SNAPSHOT.
But I agree with the change, it's the operational attributes that are of
interest when fetching it :-)
Kind Regards,
Stefan
[1]
https://github.com/apache/directory-server/blob/master/ldap-client-test/src/test/java/org/apache/directory/shared/client/api/operations/GetRootDseTest.java#L80
> diff --git
> a/ldap/client/api/src/main/java/org/apache/directory/ldap/client/api/LdapNetworkConnection.java
>
> b/ldap/client/api/src/main/java/org/apache/directory/ldap/client/api/LdapNetworkConnection.java
> index 0d425a3..26c4db2 100644
> ---
> a/ldap/client/api/src/main/java/org/apache/directory/ldap/client/api/LdapNetworkConnection.java
> +++
> b/ldap/client/api/src/main/java/org/apache/directory/ldap/client/api/LdapNetworkConnection.java
> @@ -4301,7 +4301,7 @@ public class LdapNetworkConnection extends
> AbstractLdapConnection implements Lda
> @Override
> public Entry getRootDse() throws LdapException
> {
> -return lookup( Dn.ROOT_DSE,
> SchemaConstants.ALL_USER_ATTRIBUTES_ARRAY );
> +return lookup( Dn.ROOT_DSE, SchemaConstants.ALL_ATTRIBUTES_ARRAY );
> }
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Created] (DIRAPI-374) Consistify LdapConnectionConfig useTls and useSsl flags
Stefan Seelmann created DIRAPI-374:
--
Summary: Consistify LdapConnectionConfig useTls and useSsl flags
Key: DIRAPI-374
URL: https://issues.apache.org/jira/browse/DIRAPI-374
Project: Directory Client API
Issue Type: Improvement
Affects Versions: 2.0.2
Reporter: Stefan Seelmann
Assignee: Stefan Seelmann
Fix For: 2.0.3
The {{LdapConnectionConfig}} class contains two flags {{useSsl}} and
{{useTls}}. If {{useSsl}} is true the {{SslFilter}} added to the filter chain
during {{connect()}} and the secure layer is automatically established. If
{{useTls}} is true that's not the case, the {{SslFilter}} is only added when
calling {{startTls()}} explicitly or if a simple or anonymous bind is
performed, but for example not if a SASL bind is performed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRAPI-373) Implement SASL integrity and confidentiality layer
[ https://issues.apache.org/jira/browse/DIRAPI-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17365666#comment-17365666 ] Stefan Seelmann commented on DIRAPI-373: https://github.com/apache/directory-ldap-api/commit/2cf66a14c58d4c0ddd3dd3700566a4e72cdb3518 > Implement SASL integrity and confidentiality layer > -- > > Key: DIRAPI-373 > URL: https://issues.apache.org/jira/browse/DIRAPI-373 > Project: Directory Client API > Issue Type: Improvement >Affects Versions: 2.0.2 > Reporter: Stefan Seelmann > Assignee: Stefan Seelmann >Priority: Major > Fix For: 2.0.3 > > > The LDAP API currently only implements SASL authentication, the security > layer with integrity and confidentiality is not implemented. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Created] (DIRAPI-373) Implement SASL integrity and confidentiality layer
Stefan Seelmann created DIRAPI-373: -- Summary: Implement SASL integrity and confidentiality layer Key: DIRAPI-373 URL: https://issues.apache.org/jira/browse/DIRAPI-373 Project: Directory Client API Issue Type: Improvement Affects Versions: 2.0.2 Reporter: Stefan Seelmann Assignee: Stefan Seelmann Fix For: 2.0.3 The LDAP API currently only implements SASL authentication, the security layer with integrity and confidentiality is not implemented. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
