1 |
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ |
2 |
On Sunday, July 19, 2020 6:57 PM, Ashley Dixon <ash@××××××××××.uk> wrote: |
3 |
|
4 |
> [I have stripped all mention of capitalisation, as it is off-topic here. |
5 |
> However, a seeming lack of competence in English will lead people to believe |
6 |
> that the incompetence also leaks into the code. This is especially true when |
7 |
> this lack of writing competence is intentional.] |
8 |
|
9 |
stripped, however not stripped? |
10 |
|
11 |
while there might be a correlation between |
12 |
spelling/grammar errors and bugs in software, it |
13 |
does not matter here at all because: |
14 |
|
15 |
(1) a passwords manager is too critical to have |
16 |
its reliability judged by the mere |
17 |
spellin/grammar of its dev. |
18 |
(2) nsapass has less than 500 lines of code. |
19 |
super easy to read yourself. you don't need |
20 |
to read my README.md file to deduce anything. |
21 |
|
22 |
in fact, the nsapass itself is probably about |
23 |
the size of the README.md file. |
24 |
|
25 |
> Just because something is not strongly typed and does not perform automatic |
26 |
> garbage-collection (which is very insecure for something like a password- |
27 |
> manager anyway), does not mean it is reinventing any wheels. It just forces |
28 |
> people to design their programs properly; weak typing is the absolute worst |
29 |
> feature of all these modern languages. |
30 |
|
31 |
strawman. |
32 |
|
33 |
> > and keepassxc is full of segfaults [1] |
34 |
> > [1] https://github.com/keepassxreboot/keepassxc/issues?q=segfault |
35 |
> |
36 |
> There are no open issues regarding segmentation violations. There may have been |
37 |
> at some point, but that is why I keep mentioned that the project is matured. |
38 |
|
39 |
i didn't say "open", irrelevant. latest segfaults |
40 |
are a few days old only. |
41 |
|
42 |
one of the recent segfaults is closed without |
43 |
being resolved, simply because they couldn't |
44 |
reproduce it. |
45 |
|
46 |
> Occam's Razor does not always apply. For example, forcing people to enter their |
47 |
> plain-text passwords on the command-line may be simpler than polling stdin, but, |
48 |
> surprisingly, it is not the best solution. |
49 |
|
50 |
occam's razor always applies. you're ignoring the |
51 |
fact that occam's razor doesn't blindly seek |
52 |
simplicity, but rather also looks at assumptions' |
53 |
"utility". |
54 |
|
55 |
the mathematical representation of it says: every |
56 |
assumption has a positive probability of error, so |
57 |
unless it increases accuracy/utility of the model, |
58 |
don't use extra assumptions. |
59 |
|
60 |
but if it does increase the utility, then surely |
61 |
use it. you may read the article on wiki for more |
62 |
info. |
63 |
|
64 |
> You are now againstall languages which run as native code (require a compiler |
65 |
> or linker/build system) ? Just because you did not personally write the Python |
66 |
> interpreter does not make it non-existent, and thus simple. If you want to write |
67 |
> something minimalistic and ultra-simple, why don't you use Assembly language |
68 |
> (semi-serious suggestion) ? I assure you, that is far simpler and lightweight |
69 |
> than invoking Python for every run ! |
70 |
|
71 |
no, not against. i don't know how are you getting |
72 |
these ideas. i literally told you cases where |
73 |
c/c++ is good. |
74 |
|
75 |
python has higher dev-time than keepassxcs. yes, |
76 |
python is in c, but much higher dev-time + |
77 |
auditing + bug fixes. less silly bugs. |
78 |
|
79 |
why not assembly? obviously for the same reason |
80 |
why not c/c++: (1) to keep line count small for |
81 |
convenient auditing, and (2) to avoid funny memory |
82 |
bugs. |
83 |
|
84 |
|
85 |
> Executing ./nsapass without any arguments takes around 0.054 seconds, whereas my |
86 |
> euses implementation (written in C) takes 0.002 seconds to open, buffer, search, |
87 |
> and close tens of multi-thousand-line USE-flag description files, in addition to |
88 |
> parsing a few INI files. Please, do not attack compiled languages too much; they |
89 |
> are not going anywhere for a long time. |
90 |
|
91 |
ricing doesn't matter for a passwords manager. |
92 |
this is not a low-latency high-bandwidth case. |
93 |
the delay is mainly from the user. for a pwords |
94 |
manager you mostly need (1) and (2) above (not |
95 |
ricing). |
96 |
|
97 |
> I think in virtually every case, well-designed code written in native languages |
98 |
> have an extreme performance benefit. The one counterexample might be Java (not |
99 |
> interpreted; JIT'd on-the-fly), as that has matured over such a long period of |
100 |
> time [1]. |
101 |
|
102 |
except when "performance" is defined by (1) and |
103 |
(2). |
104 |
|
105 |
> It's such a general-purpose language, it's not really "overkill" for anything. |
106 |
> Maybe an operating system or device driver, yes, but not a userspace QT |
107 |
> application ! You seem to be under the misguided impression that C and C++ are |
108 |
> low-level languages ? |
109 |
|
110 |
doesn't matter, they fail at (1) and (2). |
111 |
|
112 |
> You are capitalising (no pun intended) on this issue of memory-management, but |
113 |
> aside from a search for the term "segfault" on the KeePassXC GitHub issues page, |
114 |
> you have no evidence to suggest that your code improves upon these non-existent |
115 |
> problems. |
116 |
|
117 |
don't ignore the fact that the segfaults are |
118 |
pretty recent, and some of which is closed without |
119 |
solving :) |
120 |
|
121 |
> It is possible to write code in C/C++ which does not have memory |
122 |
> violations; you just need to know what you're accessing is valid, and perform |
123 |
> proper testing to make sure. |
124 |
|
125 |
strawman. |
126 |
|
127 |
|
128 |
> Because the GitHub-generated distribution of languages is simply incorrect. |
129 |
> There is no C in this project. Additionally, the fact that someone dare use a |
130 |
> Makefile for their C++ project is not really cause for concern. |
131 |
|
132 |
doesn't matter. more c++ less c is even worse in |
133 |
terms of project's bug risk (with c you may shoot |
134 |
your feet, with c++ you may blow your entire leg). |
135 |
|
136 |
either way, keepassxc is more complex than |
137 |
nsapass, and keepassxc fails at satisfying (1) and |
138 |
(2). |
139 |
|
140 |
> The fact that |
141 |
> someone would write almost four-hundred lines of Python with zero comments (not |
142 |
> even Python docstrings to describe functions), is a concern for me. You keep |
143 |
> mentioning how it's very easy to audit, but you certainly provide a hard time |
144 |
> for the auditor. |
145 |
|
146 |
not true. nsapass has comments. it just doesn't |
147 |
have silly comments which harm readability. e.g. |
148 |
if a 4-line function is called `print_info` it |
149 |
really doesn't need a comment. |
150 |
|
151 |
which part do you think needs a comment in |
152 |
nsapass? :) |
153 |
|
154 |
i used to comment a lot in previous apps, until i |
155 |
discovered that in many cases comments actually |
156 |
harm readability. |
157 |
|
158 |
in fact, in many cases, the moment you realize |
159 |
that your code needs lots of comments, that's also |
160 |
the moment you need to rethink ``perhaps the code |
161 |
is bad?''. |
162 |
|
163 |
because good code is not meant to be so complex |
164 |
that it needs lots of comments. |
165 |
|
166 |
> > > If you want to be creative, invent a new algorithm or program that is |
167 |
> > > indubitably superior to its predecessor, much like chip designers are doing |
168 |
> > > today. People will appreciate and respect new, beneficial ideas much more |
169 |
> > > than a few layers of free clip-art put together in GIMP. |
170 |
> > |
171 |
> > not mutually exclusive, and 2nd part is strawman |
172 |
> > (nsapass is more than layers of GIMP; the layers |
173 |
> > of GIMP is only part of the README.md content for |
174 |
> > honest and to the point dissemination of content). |
175 |
> |
176 |
> It is not a strawman argument. You do not have any grounds to say that the |
177 |
> KeePassXC model is overly complex, just because it is written in C++ with a few |
178 |
> build utilities attached, and suggesting that it is a poorly coded/designed |
179 |
> application based solely on this groundless assertion is inappropriate. |
180 |
|
181 |
sry, this one was an ad-hom. it is an adhom (you |
182 |
implied that nsapass is just a few layers of GIMP |
183 |
art). |
184 |
|
185 |
my ground is (1) and (2). and there is no "just" |
186 |
when you talk about a > 44+k lines vs. < 500. |
187 |
|
188 |
you simply cannot audit keepassxc. you need to |
189 |
trust their devs (which are still producing |
190 |
segfaults, and close unsolved issues). |
191 |
|
192 |
i'd rather put trust in python, and make the |
193 |
passwords manager fully readable. |
194 |
|
195 |
> |
196 |
> > thanks for trying. highly appreciate your time |
197 |
> > and efforts. but tbh there is no way i see to |
198 |
> > justify re-invented wheels in c++ for a passwords |
199 |
> > manager. |
200 |
> |
201 |
> Which wheel has been reinvented for KeePassXC ? Unless I'm missing something, |
202 |
> and they've rewritten malloc(3), you seem to think that "reinventing the wheel" |
203 |
> is synonymous with good design and careful memory-management. The fact that the |
204 |
> environment (in this case, the O.S.) does not do that for you does not mean the |
205 |
> developers are reinventing anything. |
206 |
|
207 |
many parts, including the encryption/decryption |
208 |
bits is not adequately trusty. |
209 |
|
210 |
on the other hand, nsapass uses scrypt by default |
211 |
(and lets you choose whatever you want). scrypt |
212 |
is much more robust against attacks than |
213 |
keepassxc's 256bit aes. |
214 |
|
215 |
plus many extra fluff, such as it being a gui app, |
216 |
is a massive overkill. a passwords manager |
217 |
doesn't need to be gui, since it's effectively |
218 |
managing some strings of texts. hence simple cli |
219 |
is more than adequate. |
220 |
|
221 |
a gui might be needed to render graphs or complex |
222 |
patterns. but to simply pick passwords/strings? |
223 |
modify some strings? nope. |
224 |
|
225 |
> > the key is not to have a "different" view. the |
226 |
> > key is to be open minded to explore different |
227 |
> > views in order to discover the "correct" view, |
228 |
> > then stick to it, while still being open to look |
229 |
> > around. but once you find the correct view, you |
230 |
> > don't leave it for the sake of adopting a |
231 |
> > different view. |
232 |
> |
233 |
> Perhaps... I'm not too sure how to respond to such a statement. If you are going |
234 |
> to accuse me of being closed-minded because I (try to) use correct English and |
235 |
> (try to) write careful and performant code, I'm don't think that this thread |
236 |
> should continue. |
237 |
|
238 |
i don't know how you read text. what happend is |
239 |
this: |
240 |
|
241 |
1. you cited a quote from a gentoo dev, about |
242 |
open mindedness. |
243 |
|
244 |
2. i don't know why you did (1.) but you did it. |
245 |
i guess you wanted to say that i'm not open |
246 |
minded because i don't agree with you. but |
247 |
doesn't matter. |
248 |
|
249 |
3. i claim that this dev's quote, which you |
250 |
cited, is wrong. |
251 |
|
252 |
4. i explain why it's wrong, and show nearest |
253 |
correct statement to that wrong statement to |
254 |
show you even better why the quote is wrong. |
255 |
|
256 |
no one is calling you close minded, let alone |
257 |
attributing it to your "proper" english. |
258 |
|
259 |
if anything, the most probable candidate for |
260 |
accusing others (of close-mindedness because of |
261 |
not using capitals) is you (you probably implied |
262 |
such accusations against me). |
263 |
|
264 |
you can't have your cake and eat it. |