Re: [gentoo-user] nsapass - alternative to keepassxc (and others)

[Ashley Dixon]

[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.]

On Sun, Jul 19, 2020 at 07:30:39AM +0000, Caveman Al Toraboran wrote:
> i'm not universally against c++, but i'm against
> it for a passwords manager, because it needlessly
> re-invents many wheels including memory management
> which is already done in other languages, such as
> python.  and a passwords manager is too critical
> to risk re-inventing such wheels.

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.

> 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.

> true, but that's not my point.  my point is the
> increased complexity by itself, from an
> occam-razorian point of view.

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.

> this is a logical consequence that follows once
> you accept that every assumption has a positive
> probability of error, by definition.
>
> then fancier build setup is effectively equivalent
> to requiring more assumptions.

You are now against _all_ 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_ !

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.

> true.  in some apps c/c++ is superior thanks to
> performance or lower level system management.

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].

> no.  thats a strawman.  you're ignoring the
> context:  passwords manager.  i'm sayin, c++ is an
> overkill for a passwords manager.

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 ?

> but c++ for a passwords manager?  nothx, i don't
> want to risk funny memory bugs around my dear
> passwords.

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.  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.

> > If people look at the image and don't read the text, then they will be
> > misinformed.
>
> i don't see where is the misinformation.  it's all
> around occam's razor and characters approved by
> the unicode consortium.

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.  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.

> > 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.

> 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.

> looks like an appeal to authority.  plus that
> gentoo dev's quote is wrong.

Gentoo developers have no authority over this matter.

> 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.

        Cheers,
        Ashley.

-- 

Ashley Dixon
suugaku.co.uk

2A9A 4117
DA96 D18A
8A7B B0D2
A30E BF25
F290 A8AA