openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#7614) Markup error in slapd.conf.5
by esr＠thyrsus.com 03 Jun '13

03 Jun '13

Howard Chu <hyc(a)symas.com>: > Hm. I use my own man2html http://highlandsun.com/hyc/man2html.c > which gives pretty good looking output for us. Really, if you're > developing a tool that claims to read troff input, it has to > actually do so. I mean, the point of tools such as this is to be > able to convert existing documents without modifying them, isn't it? There's a subtle difference between tools that translate purely at a presentation level and tools that do content analysis. A purely presentation-level translation such as your man2html is indeed less likely to be thrown by weird troff markup. And much of the time it will produce markup that doesn't look bad, especially on a relatively small collection of pages in a consistent house style. But there are things such a tool cannot do that become more important when you are translating a very large corpus of man pages with multiple authors - such as an entire Linux distribution's man page tree. Here is an example: the treatment of file paths in FILES sections. Some man-page authors mark them up as bold text. Some mark them up as italic. And some give them no highlight at all. A purely presentation-level translator will simply translate any font change from troff to HTML. In the resulting output, filenames will have three different visual signatures. Readers will thus have to work a little harder than they should to recognize filenames. A tool that does content analysis, on the other hand, can recognize presentation-level cliches that mean "this is a filename", such as a line in FILES beginning with .B or .I and containing a /, and map it to a DocBook <filename> pair. The DocBook stylesheet will then ensure that all filenames are visually marked in the *same* way in generated HTML, rather than three different ways. Now multiply this effect by all the different things that can be recognized by content - things like Unix error codes, program listings, command synopses, C function prototypes, references to other manual pages. The effect is a higher-quality and more visually uniform translation. The gain in quality increases with the diversity of the author population. For very large collections like an entire Linux distribution's man page tree it is quite significant. The tradeoff is that, while a presentation-level translator will cheerfully produce a visual garble from ill-formed troff, a tool with a real parser and a content analyzer will have a few more cases in which it just can't cope at all. Not *many* cases, mind you; in the decade I've been developing mine, perhaps 2-3%. But these are worth fixing anyway, because they're likely to break third-party man-page readers. Nothing but troff itself interprets troff perfectly. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

1 0

Re: (ITS#7612) {CLEARTEXT} password scheme broken
by h.b.furuseth＠usit.uio.no 03 Jun '13

03 Jun '13

I wrote: > This does not imply that a scheme can't be used which simply > represents the passwords as-is, nor that slapd or slap tools have > any business stripping away such a {scheme} prefix. In particular > not when that's the only way to represent cleartext passwords > starting with "{letters}". ...OTOH perhaps it's too late to change {cleartext} now if it has an established useful meaning. Could introduce a new scheme called {plaintext} or {raw} instead for this purpose. -- Hallvard

1 0

Re: (ITS#7612) {CLEARTEXT} password scheme broken
by h.b.furuseth＠usit.uio.no 03 Jun '13

03 Jun '13

On 2013-06-03 20:46, Kurt(a)OpenLDAP.org wrote: > Not a bug... > > Clear text passwords appear in userPassword without any RFC 2307 > scheme, as in > > userPassword: secret > > not: > > userPassword: {CLEARTEXT}secret That's backwards. userPassword values without a {scheme} prefix are cleartext passwords. Values with a {scheme} prefix use that scheme. This does not imply that a scheme can't be used which simply represents the passwords as-is, nor that slapd or slap tools have any business stripping away such a {scheme} prefix. In particular not when that's the only way to represent cleartext passwords starting with "{letters}". Though possibly this would mean slapd needs a tweak to how it represents non-prefixed passwords internally, if it currently uses "{cleartext}" to tell itself that. I have not looked yet. -- Hallvard

1 0

Re: (ITS#7612) {CLEARTEXT} password scheme broken
by Kurt＠OpenLDAP.org 03 Jun '13

03 Jun '13

On May 31, 2013, at 2:38 AM, wferi(a)niif.hu wrote: > Full_Name: Ferenc Wágner > Version: 2.4.31 > OS: Debian GNU/Linux squeeze > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (86.101.52.7) > > > I'm trying to store the hypothetical password "{SSHA}" in cleartext, but > slappasswd refuses to help: > > $ /usr/sbin/slappasswd -s {SSHA} -h {CLEARTEXT} > Password verification failed. > > On #openldap hbf suggested that I file an ITS ("work" in the following means > allowing binding): > > hbf: Looks like {CLEARTEXT} itself is broken. I think "userPassword: > {CLEARTEXT}secret" should work, and so that slappasswd -h {CLEARTEXT} -s secret > can output {CLEARTEXT}secret and userPassword: {CLEARTEXT}{SSHA} would be > valid. > > As I agree with him, here it is. > Not a bug... Clear text passwords appear in userPassword without any RFC 2307 scheme, as in userPassword: secret not: userPassword: {CLEARTEXT}secret A cleartext password of {SSHA} is disallowed for what should be obvious reasons. -- Kurt

1 0

Re: (ITS#7614) Markup error in slapd.conf.5
by hyc＠symas.com 03 Jun '13

03 Jun '13

Eric S. Raymond wrote: > Howard Chu <hyc(a)symas.com>: >> The patch changes much more than your bug report mentions. The error >> message you provide is pretty ambiguous, in particular you haven't >> mentioned exactly which markup element is out of order. Without this >> information we can't confirm what you're fixing. > > Globally, I'm trying to fix up the entire Linux manual page corpus so > it can be automatically lifted to clean HTML. I've been working in > this intermittently since 2002, and am not far from the goal. In > approximately 12,000 pages carried in stock Ubuntu, 94% now lift > without errors or warnings. For all but 17 of the 6% remaining I have > fix patches which I'm trying to get merged upstream. > > I entered one of those patches in your bugtracker, but failed to notice > that the error code in my bug database entry for slapd.conf.5 was > incorrect (failed to match the patch). I apologize for this; > full explanation follows. > > My conversion tool is doclifter, which you can read about at > <http://www.catb.org/~esr/doclifter/>. It lifts manual pages to > XML-DocBook, which in turn is very easily rendered to HTML. This > sequence produces better-quality HTML than tools like man2html > can generate, because of the amount of content analysis done > in the doclifter intermediate step. > There are some legal troff constructions that doclifter cannot > parse well. These are the same sorts of things that any man-page > renderer other than groff itself is likely to get wrong; thus, they > are likely to confuse tools such as XMan, TkMan, and Rosetta as well > as doclifter. Hm. I use my own man2html http://highlandsun.com/hyc/man2html.c which gives pretty good looking output for us. Really, if you're developing a tool that claims to read troff input, it has to actually do so. I mean, the point of tools such as this is to be able to convert existing documents without modifying them, isn't it? > Thhe patch I sent you introduces an .EX/.EE macro pair for framing > code examples, a common extension often found on older Unix manual > pages (I believe it originated in DEC Ultrix). This macro > encapsulates a bunch of low-level troff operations that are hard to > lift well in isolation. There's a ruleset in doclifter that recognizes > .EX/.EE, analyzes the example content, and generates <programlisting> > or <literallayout> tags as appropriate. > > In some cases .EX/.EE replaces .RS/.RE pairs; in others it replaces > .nf/.fi pairs, in still others it replaces .TP, and I think there > are a couple of odd combinations of .RS/.RE with .TP in there too. The fact > that it has to mess with all of these is what makes the patch so > complex. But the result is simple: to express the "example" intention > better so it can be structurally translated. > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7614) Markup error in slapd.conf.5
by esr＠thyrsus.com 03 Jun '13

03 Jun '13

Howard Chu <hyc(a)symas.com>: > The patch changes much more than your bug report mentions. The error > message you provide is pretty ambiguous, in particular you haven't > mentioned exactly which markup element is out of order. Without this > information we can't confirm what you're fixing. Globally, I'm trying to fix up the entire Linux manual page corpus so it can be automatically lifted to clean HTML. I've been working in this intermittently since 2002, and am not far from the goal. In approximately 12,000 pages carried in stock Ubuntu, 94% now lift without errors or warnings. For all but 17 of the 6% remaining I have fix patches which I'm trying to get merged upstream. I entered one of those patches in your bugtracker, but failed to notice that the error code in my bug database entry for slapd.conf.5 was incorrect (failed to match the patch). I apologize for this; full explanation follows. My conversion tool is doclifter, which you can read about at <http://www.catb.org/~esr/doclifter/>. It lifts manual pages to XML-DocBook, which in turn is very easily rendered to HTML. This sequence produces better-quality HTML than tools like man2html can generate, because of the amount of content analysis done in the doclifter intermediate step. There are some legal troff constructions that doclifter cannot parse well. These are the same sorts of things that any man-page renderer other than groff itself is likely to get wrong; thus, they are likely to confuse tools such as XMan, TkMan, and Rosetta as well as doclifter. Thhe patch I sent you introduces an .EX/.EE macro pair for framing code examples, a common extension often found on older Unix manual pages (I believe it originated in DEC Ultrix). This macro encapsulates a bunch of low-level troff operations that are hard to lift well in isolation. There's a ruleset in doclifter that recognizes .EX/.EE, analyzes the example content, and generates <programlisting> or <literallayout> tags as appropriate. In some cases .EX/.EE replaces .RS/.RE pairs; in others it replaces .nf/.fi pairs, in still others it replaces .TP, and I think there are a couple of odd combinations of .RS/.RE with .TP in there too. The fact that it has to mess with all of these is what makes the patch so complex. But the result is simple: to express the "example" intention better so it can be structurally translated. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

1 0

Re: (ITS#7615) NetBSD sem_open limited to 14 characters
by hyc＠symas.com 03 Jun '13

03 Jun '13

Greg(a)Akua.com wrote: > Full_Name: Greg Kerr > Version: 2.4.35 > OS: NetBSD & FreeBSD > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (50.88.130.68) > > > MDB is not usable on NetBSD because mdb.c has > > sprintf(env->me_txns->mti_wmname, "/MDBw%s", hexbuf); > > To create the semaphore name. > > This results in a 21 character name which is beyond the 14 allowed per "man > sem_open" That's unfortunate. In Linux this limit is 251 characters. Seems you'd need to use the btoa algorithm to safely fit a hash into this size limit. Pretty sure we've tested successfully on FreeBSD and MacOSX already, so apparently they don't suffer from this same limit. > "less than 14 characters in length not including the terminating null > character." > > I will make a local patch ... and maybe it's a NetBSD bug - or at least the > package maintainers ... I will report to him. > > At any rate, the failure of mdb with result code 63 (name too long) was very > confusing ... better error reporting in this file would be nice. > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7614) Markup error in slapd.conf.5
by hyc＠symas.com 03 Jun '13

03 Jun '13

esr(a)thyrsus.com wrote: > Full_Name: Eric S. Raymond > Version: > OS: Linux > URL: http://www.catb.org/~esr/doclifter/prepatch/slapd.conf.5.patch > Submission from: (NULL) (2001:470:e34c:0:226:18ff:fea6:dca4) > > > List syntax error. This means .IP, .TP or .RS/.RE markup is garbled. > Common causes include .TP just before a section header, .TP entries > with tags but no bodies, and mandoc lists with no trailing .El. > These confuse doclifter, and may also mess up stricter man-page > browsers like Xman and Rosetta. > > Fix patch at link. The patch changes much more than your bug report mentions. The error message you provide is pretty ambiguous, in particular you haven't mentioned exactly which markup element is out of order. Without this information we can't confirm what you're fixing. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7615) NetBSD sem_open limited to 14 characters
by Greg＠Akua.com 03 Jun '13

03 Jun '13

Full_Name: Greg Kerr Version: 2.4.35 OS: NetBSD & FreeBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (50.88.130.68) MDB is not usable on NetBSD because mdb.c has sprintf(env->me_txns->mti_wmname, "/MDBw%s", hexbuf); To create the semaphore name. This results in a 21 character name which is beyond the 14 allowed per "man sem_open" "less than 14 characters in length not including the terminating null character." I will make a local patch ... and maybe it's a NetBSD bug - or at least the package maintainers ... I will report to him. At any rate, the failure of mdb with result code 63 (name too long) was very confusing ... better error reporting in this file would be nice.

1 0

(ITS#7614) Markup error in slapd.conf.5
by esr＠thyrsus.com 02 Jun '13

02 Jun '13

Full_Name: Eric S. Raymond Version: OS: Linux URL: http://www.catb.org/~esr/doclifter/prepatch/slapd.conf.5.patch Submission from: (NULL) (2001:470:e34c:0:226:18ff:fea6:dca4) List syntax error. This means .IP, .TP or .RS/.RE markup is garbled. Common causes include .TP just before a section header, .TP entries with tags but no bodies, and mandoc lists with no trailing .El. These confuse doclifter, and may also mess up stricter man-page browsers like Xman and Rosetta. Fix patch at link.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs