On 24.01.24 16:06, Alan DeKok wrote:
On Jan 24, 2024, at 9:44 AM, Gerald Vogt <vogt@spamcop.net> wrote:
I tried. You have closed the issue. You see my point? You consider opening an issue just as critique and refuse from the very beginning.
For the record, the issue is this: https://github.com/FreeRADIUS/freeradius-server/issues/5012
It has a long discussion where you were asked repeatedly to explain what's wrong with the current configuration / behavior, and to offer better suggestions. That didn't happen.
On the contrary, it's all in the initial message. I wrote what's the problem with the current configuration and why it's an issue to mix up use of ca files or paths for both server and client configuration. I have outlined, on a high, conceptual level what configurations are necessary or possible to cover all those aspects. I have also gave an example how it is does it httpd mod_ssl and that there is a good reason why they have separated it. So I have made suggestions on how to improve this, how to have clear and distinguished configuration parameters for the configuration of the tls server and the tls client verification. You basically answered that you can do the things that you want to do so what's wrong? It works. I have pointed out how the comments for the configuration parameter are confusing or misleading. I don't know, where exactly those parameters are used for. I can only read the comments and try to understand what the purpose is or how they map to the standard openssl parameters like for verify. So how do you think I should know when to put the server CAs into certificate_file and when not. Or when you can use ca_file. Or ca_path. Or both. Or only either. When using client certificates. Or when not using client certificates. It is unclear, what it does exactly. So expecting someone else to clarify the documentation is kind of futile. If it's so easy and so clear, why don't you write it simply into the documentation? If I point out discrepancies or what's unclear but you shut it down. Thus, if you write " It just takes a little bit of work", then that is not helpful if that work is required because it's unclear. You may as well end up with a configuration which works but accepts much more certificates then indented. The trouble is, most people won't notice that until there is a problem. Thus, as I write in the initial message of that issue: conceptually the tls server configuration and tls client verification are two completely different aspects which can rely on two completely different ca sets. Thus, conceptually it would be better separate those. But currently, if I understand correctly, the tls server can build its chain from ca_dir and at the same time the client verification can use ca_dir, too. Also, assuming that people know that the option "ca_dir" is used as openssl "CApath", thus requires the hashes, well... "We do not include ... all of OpenSSL documentation". Let the dumb user figure it out themselves. Why should the docs indicate that ca_dir is CApath and requires c_rehash (did FR 2.x mentioned c_rehash?) You don't see how it's unclear. So why bother with anyone who finds it unclear? Not to mentioned that arr2036 also wrote "I found that extremely confusing and ended up redoing a lot of the validation logic manually." So really, I am not the only one...
So the reported problem ended up being "I don't understand how it works. I don't know how it should work. I don't know how to change it".
There is no action we can take to fix that. Which is why the issue was closed.
Yes, excellent move to shut down any attempt to clarify it. It is 'extremely confusing'...
Yes. If the person who evaluates your attempt, has a certain attitude to shoot everything down, you'll obviously ask yourself why should you even try.
A simple "git log" of the server shows that's not true. There are many, many, people who have contributed. But they take the time and effort to do so.
Well, maybe you didn't shut them down immediately. I would participate to the best of my abilities if you would shut me down with your arrogant attitude.
I am more than willing to help as I do in a lot of other projects, but I can always only contribute to the extent of my abilities (and the time I have).
As can I. Yet for some reason, that excuse is valid for you, but you don't think it's valid for me.
i.e. You don't have the time or inclination to work through the issue you opened, and you think that's fine. But if I don't do that work and instead close the issue, then I'm a bad person.
Yes. You have closed the issue instead of giving me an opportunity to make myself clearer. So you don't have the time or inclination to work through the issue I have opened, trying to understand the issue and how 'extremely confusing' it all is. And how that is even much harder for people who haven't dealt with openssl for many years and understand the basic concepts of it all.
You are disappointed that there is a large group of people who have suggestions how to improve something or who find issues in how things are, but who are not able to contribute significantly...
At the minimum, I expect contributions to be something more than "I did a bunch of stuff. It didn't work the way I expected. You need to fix it".
I did a bunch of stuff. It works for me. And I think the way I did it I think it only works the way I expect it and that there are not side effects which are allowed. But I only got to that point but not really following what is clearly mentioned in the comments. I got to that point by briefly checking the source code to get some idea where those parameters might be used and how they map down to the common openssl configurations for tls servers and client verification. I got to that point because I think I understood the mixed used of some of those parameters for tls servers and client verification from that, thus separating it by a certain way of configuration, from experience with openssl. So it works and I hope it really only works the way I expect it. But to clarify the documentation is difficult if you don't have a deeper understanding of where everything is used exactly. It'll takes me hours to figure that out, what a developer just knows...
You can either pick that up, show some interest and start a discussion which could well go deeper, or you can simply be disappointed and tell people that they "have time and energy to criticize, but none to contribute", expecting them (between the lines) to provides fully finished code patches which you can review.
We both know hat isn't what I said. I've asked you for documentation updates, or for a clearer description of the problem. Oh. Yes. That's very much what you basically said, whether you call it "documentation updates" now. If you asking for a PR that's what you do.
The documentation is unclear. I have to guess what the documentation means. You ask me for documentation updates. How am I supposed to give you a documentation update from some guesses? That documentation won't get any better, it's just another guess. The problem in the end is, that you don't even acknowledge that the documentation is misleading, confusing and sometimes simply wrong. I know it's easier to find out that it's wrong, and harder to write it correctly, which requires an understanding of it. But that doesn't come from a guess deducted from a misleading documentation... I cannot write documentation on what "ca_file" and "ca_dir" does exactly when I don't know what it does exactly and where it's used. It may be used for tls server or client verification or both, and maybe only ca_file if it's defined or maybe both, or maybe only one in certain situations. That is the problem. How much clearer do you need it? I can guess and write an update, although I hardly know if it's so much more accurate...
If you need to lie in order to "win" an argument, that's a lot more problematic than my "negative" attitude of asking you to a little bit of work.
I don't have to win this argument. I know by know that you won't change and you won't bother even trying to understand. You always win the argument because you have the power and if people don't do what you tell them to do then you can just simply shut them down.
I would love to participate and contribute
Apparently not.
I do. But you really working very hard to make me change my mind. You must really think, I have nothing better to do then write lengthy replies trying to explain my point, even though I am pretty sure that I won't get through to you... But I suppose it is what it is. If you don't immediately understand an issue it's obviously the fault of the other person. I mean in the github issue above I wasn't the only one who finds it confusing... And from many mails here on this list I think it also should be clear that it's confusing. Anyways, I guess I spent enough time on this. I have explained originally to someone else how I understand how it works and how it needs to be configured. You don't like that either, but have to put in your standard "Patches are welcome", which of course is obviously more then rhetoric by you, because you know that it's pretty unlikely that the average person would quickly rewrite the use of certificates and submit a patch... I have explained to someone else the trusted and untrusted certificates. If that's a problem for you or doesn't fit your standards, well, no need to repeat your "patches are welcome"... Over and out, Gerald