??????? Original Message ???????
On Sunday, July 19, 2020 6:57 PM, Ashley Dixon <ash@suugaku.co.uk> wrote:
> [.I have stripped all mention of capitalisation, as it is off-topic here.
> However, a seeming lack of competence in English will lead people to believe
> that the incompetence also leaks into the code. This is especially true when
> this lack of writing competence is intentional.]
stripped, however not stripped?
while there might be a correlation between
spelling/grammar errors and bugs in software, it
does not matter here at all because:
(1) a passwords manager is too critical to have
its reliability judged by the mere
spellin/grammar of its dev.
(2) nsapass has less than 500 lines of code.
super easy to read yourself. you don't need
to read my README.md file to deduce anything.
in fact, the nsapass itself is probably about
the size of the README.md file.
> Just because something is not strongly typed and does not perform automatic
> garbage-collection (which is very insecure for something like a password-
> manager anyway), does not mean it is reinventing any wheels. It just forces
> people to design their programs properly; weak typing is the absolute worst
> feature of all these modern languages.
strawman.
> > and keepassxc is full of segfaults [1]
> > [1] https://github.com/keepassxreboot/keepassxc/issues?q=segfault
>
> There are no open issues regarding segmentation violations. There may have been
> at some point, but that is why I keep mentioned that the project is matured.
i didn't say "open", irrelevant. latest segfaults
are a few days old only.
one of the recent segfaults is closed without
being resolved, simply because they couldn't
reproduce it.
> Occam's Razor does not always apply. For example, forcing people to enter their
> plain-text passwords on the command-line may be simpler than polling stdin, but,
> surprisingly, it is not the best solution.
occam's razor always applies. you're ignoring the
fact that occam's razor doesn't blindly seek
simplicity, but rather also looks at assumptions'
"utility".
the mathematical representation of it says: every
assumption has a positive probability of error, so
unless it increases accuracy/utility of the model,
don't use extra assumptions.
but if it does increase the utility, then surely
use it. you may read the article on wiki for more
info.
> You are now againstall languages which run as native code (require a compiler
> or linker/build system) ? Just because you did not personally write the Python
> interpreter does not make it non-existent, and thus simple. If you want to write
> something minimalistic and ultra-simple, why don't you use Assembly language
> (semi-serious suggestion) ? I assure you, that is far simpler and lightweight
> than invoking Python for every run !
no, not against. i don't know how are you getting
these ideas. i literally told you cases where
c/c++ is good.
python has higher dev-time than keepassxcs. yes,
python is in c, but much higher dev-time +
auditing + bug fixes. less silly bugs.
why not assembly? obviously for the same reason
why not c/c++: (1) to keep line count small for
convenient auditing, and (2) to avoid funny memory
bugs.
> Executing ./nsapass without any arguments takes around 0.054 seconds, whereas my
> euses implementation (written in C) takes 0.002 seconds to open, buffer, search,
> and close tens of multi-thousand-line USE-flag description files, in addition to
> parsing a few INI files. Please, do not attack compiled languages too much; they
> are not going anywhere for a long time.
ricing doesn't matter for a passwords manager.
this is not a low-latency high-bandwidth case.
the delay is mainly from the user. for a pwords
manager you mostly need (1) and (2) above (not
ricing).
> I think in virtually every case, well-designed code written in native languages
> have an extreme performance benefit. The one counterexample might be Java (not
> interpreted; JIT'd on-the-fly), as that has matured over such a long period of
> time [1].
except when "performance" is defined by (1) and
(2).
> It's such a general-purpose language, it's not really "overkill" for anything.
> Maybe an operating system or device driver, yes, but not a userspace QT
> application ! You seem to be under the misguided impression that C and C++ are
> low-level languages ?
doesn't matter, they fail at (1) and (2).
> You are capitalising (no pun intended) on this issue of memory-management, but
> aside from a search for the term "segfault" on the KeePassXC GitHub issues page,
> you have no evidence to suggest that your code improves upon these non-existent
> problems.
don't ignore the fact that the segfaults are
pretty recent, and some of which is closed without
solving :)
> It is possible to write code in C/C++ which does not have memory
> violations; you just need to know what you're accessing is valid, and perform
> proper testing to make sure.
strawman.
> Because the GitHub-generated distribution of languages is simply incorrect.
> There is no C in this project. Additionally, the fact that someone dare use a
> Makefile for their C++ project is not really cause for concern.
doesn't matter. more c++ less c is even worse in
terms of project's bug risk (with c you may shoot
your feet, with c++ you may blow your entire leg).
either way, keepassxc is more complex than
nsapass, and keepassxc fails at satisfying (1) and
(2).
> The fact that
> someone would write almost four-hundred lines of Python with zero comments (not
> even Python docstrings to describe functions), is a concern for me. You keep
> mentioning how it's very easy to audit, but you certainly provide a hard time
> for the auditor.
not true. nsapass has comments. it just doesn't
have silly comments which harm readability. e.g.
if a 4-line function is called `print_info` it
really doesn't need a comment.
which part do you think needs a comment in
nsapass? :)
i used to comment a lot in previous apps, until i
discovered that in many cases comments actually
harm readability.
in fact, in many cases, the moment you realize
that your code needs lots of comments, that's also
the moment you need to rethink ``perhaps the code
is bad?''.
because good code is not meant to be so complex
that it needs lots of comments.
> > > If you want to be creative, invent a new algorithm or program that is
> > > indubitably superior to its predecessor, much like chip designers are doing
> > > today. People will appreciate and respect new, beneficial ideas much more
> > > than a few layers of free clip-art put together in GIMP.
> >
> > not mutually exclusive, and 2nd part is strawman
> > (nsapass is more than layers of GIMP; the layers
> > of GIMP is only part of the README.md content for
> > honest and to the point dissemination of content).
>
> It is not a strawman argument. You do not have any grounds to say that the
> KeePassXC model is overly complex, just because it is written in C++ with a few
> build utilities attached, and suggesting that it is a poorly coded/designed
> application based solely on this groundless assertion is inappropriate.
sry, this one was an ad-hom. it is an adhom (you
implied that nsapass is just a few layers of GIMP
art).
my ground is (1) and (2). and there is no "just"
when you talk about a > 44+k lines vs. < 500.
you simply cannot audit keepassxc. you need to
trust their devs (which are still producing
segfaults, and close unsolved issues).
i'd rather put trust in python, and make the
passwords manager fully readable.
>
> > thanks for trying. highly appreciate your time
> > and efforts. but tbh there is no way i see to
> > justify re-invented wheels in c++ for a passwords
> > manager.
>
> Which wheel has been reinvented for KeePassXC ? Unless I'm missing something,
> and they've rewritten malloc(3), you seem to think that "reinventing the wheel"
> is synonymous with good design and careful memory-management. The fact that the
> environment (in this case, the O.S.) does not do that for you does not mean the
> developers are reinventing anything.
many parts, including the encryption/decryption
bits is not adequately trusty.
on the other hand, nsapass uses scrypt by default
(and lets you choose whatever you want). scrypt
is much more robust against attacks than
keepassxc's 256bit aes.
plus many extra fluff, such as it being a gui app,
is a massive overkill. a passwords manager
doesn't need to be gui, since it's effectively
managing some strings of texts. hence simple cli
is more than adequate.
a gui might be needed to render graphs or complex
patterns. but to simply pick passwords/strings?
modify some strings? nope.
> > the key is not to have a "different" view. the
> > key is to be open minded to explore different
> > views in order to discover the "correct" view,
> > then stick to it, while still being open to look
> > around. but once you find the correct view, you
> > don't leave it for the sake of adopting a
> > different view.
>
> Perhaps... I'm not too sure how to respond to such a statement. If you are going
> to accuse me of being closed-minded because I (try to) use correct English and
> (try to) write careful and performant code, I'm don't think that this thread
> should continue.
i don't know how you read text. what happend is
this:
1. you cited a quote from a gentoo dev, about
open mindedness.
2. i don't know why you did (1.) but you did it.
i guess you wanted to say that i'm not open
minded because i don't agree with you. but
doesn't matter.
3. i claim that this dev's quote, which you
cited, is wrong.
4. i explain why it's wrong, and show nearest
correct statement to that wrong statement to
show you even better why the quote is wrong.
no one is calling you close minded, let alone
attributing it to your "proper" english.
if anything, the most probable candidate for
accusing others (of close-mindedness because of
not using capitals) is you (you probably implied
such accusations against me).
you can't have your cake and eat it.
