[GH-ISSUE #1349] Disclose LLM usage in README #473

Open
opened 2026-02-27 08:17:28 +03:00 by kerem · 2 comments
Owner

Originally created by @maciek134 on GitHub (Nov 11, 2025).
Original GitHub issue: https://github.com/lldap/lldap/issues/1349

It would be nice if the usage of LLM(s) to write this code would be disclosed - especially since you are asking for financial support.

Opinions and ethical dilemmas aside, a lot of people (me included) would rather waste a couple hours setting up OpenLDAP than trust LLM output when it comes to user credentials.

Originally created by @maciek134 on GitHub (Nov 11, 2025). Original GitHub issue: https://github.com/lldap/lldap/issues/1349 It would be nice if the usage of LLM(s) to write this code would be disclosed - especially since you are asking for financial support. Opinions and ethical dilemmas aside, a lot of people (me included) would rather waste a couple hours setting up OpenLDAP than trust LLM output when it comes to user credentials.
Author
Owner

@nitnelave commented on GitHub (Nov 12, 2025):

That's a fair point, and I understand the feeling. Before I make any changes to the repository, I want to share a few things here:

  • on the financial support part, this is not for me personally (my day job is enough for me) but rather to be able to justify spending money on LLDAP: whether that is to buy a logo or other assets, to offer a bug bounty, or if it comes to that to hire someone to work on it. It currently stands at less than 20 dollars a month, so with the entire amount I got I can probably pay for one minor bugfix :D
  • regarding LLMs, I do admit that a couple of my PRs were written by an agent (copilot). Those were minor tasks (no-op refactorings, small/obvious bug fixes). Others may have submitted PRs using LLMs as a tool to write them, I can't always know. However, I stand by all the code that was written and submitted: I have read and understood every line of Rust in the repository, be it written by me, an agent, or a contributor. There was never any vibe coding involved on my part.

My stance on LLMs is that they're a tool, like an editor: you wouldn't reject a project because it was written with Vim rather than Emacs. How you write the code doesn't matter as much as the quality of the code produced, and the knowledge of the maintainers (see Programming as Theory Building). In that way, I have used LLMs to be able to write from my phone what I knew I wanted to write, and could not find the time in front of a computer to do (I have very limited spare time these days, and it's easier to snatch 5 minutes on the phone here and there). I don't delegate the thinking to an agent.

Now, with all that said, when choosing LLDAP, a few caveats come up:

  • this is a hobby project maintained by one guy in his little spare time. Development is slow, and so would be responses to security bugs. The bus factor is one, and if I stop working on the project it'll be essentially archived.
  • I am not a security engineer (nor a frontend or DB engineer), and the code has not been reviewed for security (though I try my best).
  • LLDAP is prone to DoS, it has no protection against that; if this becomes a concern, it would have to be implemented at the proxy level.
  • Compared to OpenLDAP, it is most probably less secure.
  • it is aimed at hobbyists who self-host and want a simple LDAP server as the common protocol everyone speaks. Use cases outside of that are out of scope (though they may be incidentally supported)
  • and last but not least, as the license says, THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND

If you hang out on the Discord server, you'll see that I have never made any claims about LLDAP's security, apart from being horrified at the suggestion that someone run it in a hospital 😅

<!-- gh-comment-id:3519341223 --> @nitnelave commented on GitHub (Nov 12, 2025): That's a fair point, and I understand the feeling. Before I make any changes to the repository, I want to share a few things here: - on the financial support part, this is not for me personally (my day job is enough for me) but rather to be able to justify spending money on LLDAP: whether that is to buy a logo or other assets, to offer a bug bounty, or if it comes to that to hire someone to work on it. It currently stands at less than 20 dollars a month, so with the entire amount I got I can probably pay for one minor bugfix :D - regarding LLMs, I do admit that a couple of my PRs were written by an agent (copilot). Those were minor tasks (no-op refactorings, small/obvious bug fixes). Others may have submitted PRs using LLMs as a tool to write them, I can't always know. However, I stand by all the code that was written and submitted: I have read and understood every line of Rust in the repository, be it written by me, an agent, or a contributor. There was never any vibe coding involved on my part. My stance on LLMs is that they're a tool, like an editor: you wouldn't reject a project because it was written with Vim rather than Emacs. How you write the code doesn't matter as much as the quality of the code produced, and the knowledge of the maintainers (see Programming as Theory Building). In that way, I have used LLMs to be able to write from my phone what I knew I wanted to write, and could not find the time in front of a computer to do (I have very limited spare time these days, and it's easier to snatch 5 minutes on the phone here and there). I don't delegate the thinking to an agent. Now, with all that said, when choosing LLDAP, a few caveats come up: - this is a hobby project maintained by one guy in his little spare time. Development is slow, and so would be responses to security bugs. The bus factor is one, and if I stop working on the project it'll be essentially archived. - I am not a security engineer (nor a frontend or DB engineer), and the code has not been reviewed for security (though I try my best). - LLDAP is prone to DoS, it has no protection against that; if this becomes a concern, it would have to be implemented at the proxy level. - Compared to OpenLDAP, it is most probably less secure. - it is aimed at hobbyists who self-host and want a simple LDAP server as the common protocol everyone speaks. Use cases outside of that are out of scope (though they may be incidentally supported) - and last but not least, as the license says, THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND If you hang out on the Discord server, you'll see that I have never made any claims about LLDAP's security, apart from being horrified at the suggestion that someone run it in a hospital 😅
Author
Owner

@maciek134 commented on GitHub (Nov 12, 2025):

To be clear, I fully understand that this project is a one-man-hobby-no-guarantees thing. I only touched on funding because I was considering using lldap for a small commercial project and I like to give back when that happens.

I didn't want to suggest any full-blown vibe coding happened, but thank you for clearing it up and sorry for my choice of words.

I wouldn't compare LLMs to editors - vim wasn't built on petabytes of (verifiably) stolen IP and it doesn't take a small town's worth of electricity to create something with it.

Btw I found vim on termux very capable when it comes to writing code on the go :)

Thank you for the response!

<!-- gh-comment-id:3521562432 --> @maciek134 commented on GitHub (Nov 12, 2025): To be clear, I fully understand that this project is a one-man-hobby-no-guarantees thing. I only touched on funding because I was considering using lldap for a small commercial project and I like to give back when that happens. I didn't want to suggest any full-blown vibe coding happened, but thank you for clearing it up and sorry for my choice of words. I wouldn't compare LLMs to editors - vim wasn't built on petabytes of (verifiably) stolen IP and it doesn't take a small town's worth of electricity to create something with it. Btw I found vim on termux very capable when it comes to writing code on the go :) Thank you for the response!
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/lldap-lldap#473
No description provided.