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

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

[Caveman Al Toraboran]

hi - recently i heard some guys were suffering in
this list from keepassxc, which reminded me of my
my own.  so i finally decided to put an end to
this in 404 lines of py code:

    https://github.com/Al-Caveman/nsapass

hth.

rgrds,
cm.

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

[Ashley Dixon]

[-- Attachment #1: Type: text/plain, Size: 3041 bytes --]

On Fri, Jul 17, 2020 at 05:15:01AM +0000, Caveman Al Toraboran wrote:
> hi - recently i heard some guys were suffering in
> this list from keepassxc, which reminded me of my
> my own.  so i finally decided to put an end to
> this in 404 lines of py code:
> 
>     https://github.com/Al-Caveman/nsapass

I haven't downloaded it yet, but I think you should rephrase the README  on  the
GitHub page.  Instead of constantly explaining the reasons you dislike KeePassXC
in particular, it would be more attractive to explain the merits of  your  _own_
program, and why people---who may have never used any  password-manager---should
download NSAPass.  There are also quite a few  spelling  and  grammar  mistakes,
which I suggest you fix before tagging the next release.

It is not my place to criticise your opposition to capital letters  (although  I
do not personally understand it myself), but if you want to garner a  serious  a
serious user-base, you will need to write your README and  code  comments  in  a
more professional manner.  Currently, users and contributors might be  repelled.

Irrelevant aside.  You mention that one of the reasons that NSAPass is  superior
to KeePassXC is the GitHub-generated distributions of languages: please  realise
that this is often grossly inaccurate, and is probably not  something  on  which
you should capitalise in your critique of the project.  Rest assured, the entire
project is written in C++, with header files  being  erroneously  classified  as
plain C [1].  The Objective C++  is  a  very  small  proportion  of  the  entire
codebase, used for MacOSX-specific builds, and everything else just consists  of
build utilities and scripts.  Thankfully, GitHub uses `linguist`  for  automatic
language-detection, which supports a manual override [2], although this  feature
is unknown to most.

Although it's wonderful that you're writing good code for others to use (and one
of the best ways to learn programming), it is not a  good  idea  to  start  your
endeavours by placing  the  logo  of  a  seven-year-matured  project  with  over
two-hundred contributors and many commercial sponsors next to some  clip-art  of
an unpleasant animalistic product (the most courteous  description  of  which  I
could think) and some out-of-date cheese.

Other than the "vanity" issues, it looks alright; you've clearly put quite a bit
of effort into its development. Once it's matured for a few more months, and you
pick up a small user-base, you could post it to Gentoo-Dev (as  I  did  with  my
latest project [3]) and see if it gets picked up by anyone  wanting  to  put  it
into the Portage tree (gentoo.git).

        Hope this helps,
        Ashley.

[1] https://github.com/keepassxreboot/keepassxc/search?l=c
[2] https://github.com/github/linguist#using-gitattributes
[3] https://archives.gentoo.org/gentoo-dev/message/fa864fb2169d4c80075a7c97604a747d

-- 

Ashley Dixon
suugaku.co.uk

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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Caveman Al Toraboran]

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, July 17, 2020 2:32 PM, Ashley Dixon <ash@suugaku.co.uk> wrote:

> I haven't downloaded it yet, but I think you should rephrase the README on the
> GitHub page. Instead of constantly explaining the reasons you dislike KeePassXC
> in particular, it would be more attractive to explain the merits of your own
> program, and why people---who may have never used any password-manager---should
> download NSAPass. There are also quite a few spelling and grammar mistakes,
> which I suggest you fix before tagging the next release.

thanks.  yeah, i should add a section probably for
totally new people.  but not sure i have the time
for this, which is why i also communicated my
ideas in the most efficient way my brain can
produce.

i also agree with you that not expressing dislike
towards an app may help me make new friends,
because unfortunately we live in a time where
people get triggered by almost anything.

but imo there is another side to it: if we let
fear take from us our right to express dislike
towards an ``app'' then next generation people
will have more buggy software.  do we want our
children, or grand children, to have more bugs?
1st step starts here!

i also don't get why one shouldn't express his
dislike towards an ``app''.  ``don't insult my
app'' is now a thing?

imo if ppl keep advancing towards this direction,
we'll end up getting detached from reality, and
live in an abstract space where everyone is 100%
happy despite the fact being 100% out of touch
with reality (ultimately).

> It is not my place to criticise your opposition to capital letters (although I
> do not personally understand it myself), but if you want to garner a serious a
> serious user-base, you will need to write your README and code comments in a
> more professional manner. Currently, users and contributors might be repelled.

that's fine.  i made this app to address a
requirement of mine, then shared it in case it
helps others.  if someone doesn't want to use my
app that's fine.  i'd still use it regardless.

if someone is too superficial/arrogant and picks
on unrelated issues (e.g. use of capitals), then
tbh i may actually prefer him to not use my
app.  so in a sense not using capitals is a
feature.  superficial/arrogant people are sort of
vandalizes as they occupy a communication channel
only to end up wasting time in unproductive
discussions.


> Irrelevant aside. You mention that one of the reasons that NSAPass is superior
> to KeePassXC is the GitHub-generated distributions of languages: please realise
> that this is often grossly inaccurate, and is probably not something on which
> you should capitalise in your critique of the project. Rest assured, the entire
> project is written in C++, with header files being erroneously classified as
> plain C [1]. The Objective C++ is a very small proportion of the entire
> codebase, used for MacOSX-specific builds, and everything else just consists of
> build utilities and scripts. Thankfully, GitHub uses `linguist` for automatic
> language-detection, which supports a manual override [2], although this feature
> is unknown to most.

yeah, however, two points:

(1) imo build utilities is still part of the app
    since the app cannot run without them.  imo we
    may call them ``build-time parts of the app'',
    which will still affect the run-time of the
    app.  so it is still a relevant indicator of
    project's complexity imo.  otoh, nsapass uses
    a single py file for everything, hence none of
    that complexity.

(2) my main reason for that is to show that they
    are implemented mostly in c++ which is a nice
    tool to lose a leg (as bjarne stroustrup puts
    it).  so if it's 100% c++, then it's even
    scarier.


> Although it's wonderful that you're writing good code for others to use (and one
> of the best ways to learn programming), it is not a good idea to start your
> endeavours by placing the logo of a seven-year-matured project with over
> two-hundred contributors and many commercial sponsors next to some clip-art of
> an unpleasant animalistic product (the most courteous description of which I
> could think) and some out-of-date cheese.

(1) it makes it more efficient because a person
    who looks at the image, and didnt' still read
    much of the text, he'd be more likely to tell
    from the graph that ``yeah complexity is bad''
    (thanks to the clip arts).

(2) it's funny imo.  playfulness is a prerequisite
    of creativity.  imo it's good to play around a
    bit.  the opposite to it is "efficiency" i
    guess?  if we operate in an efficient mode,
    then we will are optimized for completing
    paperwork-like tasks, but with much less
    creativity.

(3) imo keepassxc's devs are too smart to be
    emotionally hurt because random neckbeard in
    the interwebs doesn't like their apps.

    but, hypothetically, in case there existed a
    dev who gets triggered by such things, then it
    is an indication of low intelligence which
    is yet another reason to not run his code.

this video is not very related, but thought
sharing it might help, since i think this problem
is a special case of a much bigger problem, and a
battle that we're losing generation after
generation:

    https://www.youtube.com/watch?v=BtWrljX9HRA


> Other than the "vanity" issues, it looks alright; you've clearly put quite a bit
> of effort into its development. Once it's matured for a few more months, and you
> pick up a small user-base, you could post it to Gentoo-Dev (as I did with my
> latest project [3]) and see if it gets picked up by anyone wanting to put it
> into the Portage tree (gentoo.git).

nice tip.  ty.  highly appreciate your time.

rgrds,
cm

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

[Ashley Dixon]

[-- Attachment #1: Type: text/plain, Size: 8673 bytes --]

On Sat, Jul 18, 2020 at 04:30:22PM +0000, Caveman Al Toraboran wrote:
> i also agree with you that not expressing dislike
> towards an app may help me make new friends,
> because unfortunately we live in a time where
> people get triggered by almost anything.

I did not mention people getting "triggered", and certainly did  not  imply  it.
Before an unfortunate web-search, I did not even know the meaning of that  term.

> but imo there is another side to it: if we let
> fear take from us our right to express dislike
> towards an ``app'' then next generation people
> will have more buggy software.  do we want our
> children, or grand children, to have more bugs?
> 1st step starts here!

Yes.  I have a one-year-old daughter, and I have been telling her from  a  young
age to replace matured code-bases with four-hundred lines of Python coupled with
docs that look like they've been written by a victim  of  "shift-key-theft:  the
coolest of all crimes." (Professor, Futurama) ;-)

More seriously, your view of software development is quite severely warped. More
on this below.

> i also don't get why one shouldn't express his
> dislike towards an ``app''.  ``don't insult my
> app'' is now a thing?

You have reduced rational debate with KeePassXC's coding  styles  to  the  point
seen on your GitHub README.  I don't think it's still rational debate,  at  this
stage.

> imo if ppl keep advancing towards this direction,
> we'll end up getting detached from reality, and
> live in an abstract space where everyone is 100%
> happy despite the fact being 100% out of touch
> with reality (ultimately).

This sociological position may be valid, but please understand that  I  was  not
suggesting you "don't insult" them.  But placing a picture of  a  shit  next  to
their project name based solely on the fact it is  written  in  C++  instead  of
Python, does not cast your project (or you) in the greatest of lights.

I'm not sure why you're so against C++ ?  It is certainly  not  perfect,  as  it
allows inherently poorly written code (Java, for example, tries to enforce  good
coding styles a bit more), but that is no reason to (quite  literally)  shit  on
any project/programmers using it.  Having a quick review of the KeePassXC  code-
base, I can say with reasonable  confidence,  that  it  is  written  to  a  very
professional standard.

>> [Re: Usage (or lack thereof) of Capital Letters]

> that's fine.  i made this app to address a
> requirement of mine, then shared it in case it
> helps others.  if someone doesn't want to use my
> app that's fine.  i'd still use it regardless.

That's OK.  I have no problem with that, aside from not personally understanding
it myself.  However, the complete lack of capital letters does make your project
look juvenile.

> if someone is too superficial/arrogant and picks
> on unrelated issues (e.g. use of capitals), then
> tbh i may actually prefer him to not use my
> app.  so in a sense not using capitals is a
> feature.  superficial/arrogant people are sort of
> vandalizes as they occupy a communication channel
> only to end up wasting time in unproductive
> discussions.

However, I do have a rather significant issue with you calling those you dare to
use the English language correctly "superficial" and "arrogant".  I'm not  going
to say too much here, as I don't want to get into  an  argument  over  something
completely off-topic, but I strongly  advise  that  you  stop  confusing  "cool,
quirky, and different" with "semantically incorrect".

The best way to make your project stand out  is  to  make  it  of  exceptionally
quality, usability, and stability.  You really don't want the complete  lack  of
spelling and grammar to be your entire project's unique claim-to-fame.

>> [Re: GitHub Distribution of Languages]

> yeah, however, two points:
> 
> (1) imo build utilities is still part of the app
>     since the app cannot run without them.  imo we
>     may call them ``build-time parts of the app'',
>     which will still affect the run-time of the
>     app.  so it is still a relevant indicator of
>     project's complexity imo.  otoh, nsapass uses
>     a single py file for everything, hence none of
>     that complexity.

The fact that a project _has_ a build utility is a really, really poor vector of
attack.  If the build utility did not work, or was a virus, or  _anything  other
than a good build utility_, then you may use  that  to  discredit  the  project.
However, criticising the mere existence of a few Makefiles and automated testing
scripts is a monumentally BAD idea.

It turns out that they exist to aid the main code-base.

> (2) my main reason for that is to show that they
>     are implemented mostly in c++ which is a nice
>     tool to lose a leg (as bjarne stroustrup puts
>     it).  so if it's 100% c++, then it's even
>     scarier.

C and C++ are certainly double-edged swords; I've been writing code in C since I
was about twelve years of age.  Fortunately, the nice thing about a double-edged
sword is that one of the "edges" work in your favour.  If you (over two-hundred-
and-thirty individual contributors) work at ensuring the quality  of  a  project
over a period of seven years, in whatever language, it's very  likely  that  few
legs are to be lost.

You're essentially saying that all C++ code is of poor quality.  Do you honestly
think that such an observation is correct ?

>> [Re: Usage of Arguably Ill-Chosen Clip-Art]

> (1) it makes it more efficient because a person
>     who looks at the image, and didnt' still read
>     much of the text, he'd be more likely to tell
>     from the graph that ``yeah complexity is bad''
>     (thanks to the clip arts).

If people look at the  image  and  don't  read  the  text,  then  they  will  be
misinformed.  I must say, this is probably the weirdest and most invalid  method
of attacking another project I've ever seen: the  GitHub-generated  distribution
of languages ?  Please do not take offence, but I cannot resist  laughing  while
writing this; your method of advertising a product it is quite absurd.

> (2) it's funny imo.  playfulness is a prerequisite
>     of creativity.  imo it's good to play around a
>     bit.  the opposite to it is "efficiency" i
>     guess?  if we operate in an efficient mode,
>     then we will are optimized for completing
>     paperwork-like tasks, but with much less
>     creativity.

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.

> (3) imo keepassxc's devs are too smart to be
>     emotionally hurt because random neckbeard in
>     the interwebs doesn't like their apps.

I don't know how smart the developers are, and you're correct that you shouldn't
really worry about "hurting their feelings" (as they're  probably  all  adults).
With my critique of your project's "image", I was talking less of  the  ways  in
which you annoy someone else, but to the  extents  to  which  your  comments  on
existing technologies reflect on your project.

> this video is not very related, but thought
> sharing it might help, since i think this problem
> is a special case of a much bigger problem, and a
> battle that we're losing generation after
> generation:
> 
>     https://www.youtube.com/watch?v=BtWrljX9HRA

I am not trying to stifle your freedom of speech, but I am  trying  to  convince
you  that  it  is  important  to  provide  a  balanced  analysis   of   previous
technologies.  Doing so will probably significantly aid the development of  your
program, as you can borrow ideas and build upon them.

As a prominent Gentoo developer once told me, "you do need to take  a  different
look at the world".  You also need to understand  the  meaning  of  "freedom  of
speech", as this is something about which many of the  younger  generations  are
confused: I am not a Governmental organisation, I am not trying  to  detain  you
for your views, and your right to freedom of speech does not  protect  you  from
all critique.

        Hope this helps,
        Ashley.

P.S.  I have not yet watched that Oxford Union video, but I will do when  I  get
some time. Cheers for the link; those speeches are generally interesting.

-- 

Ashley Dixon
suugaku.co.uk

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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Caveman Al Toraboran]

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, July 18, 2020 10:28 PM, Ashley Dixon <ash@suugaku.co.uk> wrote:

> This sociological position may be valid, but please understand that I was not
> suggesting you "don't insult" them. But placing a picture of a shit next to
> their project name based solely on the fact it is written in C++ instead of
> Python, does not cast your project (or you) in the greatest of lights.

i don't see the problem.  the unicode consortium
says the pile of sh*t is a normal character.

alternatively, i can replace the sh*t character by
a blown off leg, alongside the bjarne stroustrup
quote about c++.

> I'm not sure why you're so against C++ ? It is certainly not perfect, as it
> allows inherently poorly written code (Java, for example, tries to enforce good
> coding styles a bit more), but that is no reason to (quite literally) shit on
> any project/programmers using it. Having a quick review of the KeePassXC code-
> base, I can say with reasonable confidence, that it is written to a very
> professional standard.

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.

and keepassxc is full of segfaults [1]

[1] https://github.com/keepassxreboot/keepassxc/issues?q=segfault

> That's OK. I have no problem with that, aside from not personally understanding
> it myself. However, the complete lack of capital letters does make your project
> look juvenile.

thanks.  that's a feature.  it's by design.  i
hope my writing style functions as repellent of
superficial ppl.

> However, I do have a rather significant issue with you calling those you dare to
> use the English language correctly "superficial" and "arrogant".

i didn't say that.  people are free to waste their
time by capitalizing what they want.  people are
also free to advise others on wat they think is
better.

but what i'm saying is different:  if someone
rejects my app simply because i don't capetalize
in my writings in README.md, then nothx don't use
my app.

> I'm not going
> to say too much here, as I don't want to get into an argument over something
> completely off-topic, but I strongly advise that you stop confusing "cool,
> quirky, and different" with "semantically incorrect".

you already did, but thx for advise.

> The best way to make your project stand out is to make it of exceptionally
> quality, usability, and stability. You really don't want the complete lack of
> spelling and grammar to be your entire project's unique claim-to-fame.

it's already more stable than keepassxc.  spelling
of README.md is unrelated.

nsapass is slightly over 400 lines of py code.
super easy to audit.  one doesn't need to guess
code reliability based on my spelling in
README.md.

alternatively, if my spelling in README.md is too
scary/offensive, people are free to use the
thousands of c++ lines of keepassxc code and
segfault away from me.

> The fact that a projecthas a build utility is a really, really poor vector of
> attack. If the build utility did not work, or was a virus, or anything other
> than a good build utility, then you may use that to discredit the project.However, criticising the mere existence of a few Makefiles and automated testing
> scripts is a monumentally BAD idea.

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

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.


> It turns out that they exist to aid the main code-base.

true, their main code-base system needs extra
assumptions in order to operate.

> C and C++ are certainly double-edged swords; I've been writing code in C since I
> was about twelve years of age. Fortunately, the nice thing about a double-edged
> sword is that one of the "edges" work in your favour. If you (over two-hundred-
> and-thirty individual contributors) work at ensuring the quality of a project
> over a period of seven years, in whatever language, it's very likely that few
> legs are to be lost.

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

> You're essentially saying that all C++ code is of poor quality. Do you honestly
> think that such an observation is correct ?

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

feel free to use c++ for lower level
things like a games engine that demands high
performance, in fact i'd recommend c/c++ for some
cases, such as a gaming engine, or stuff that need
high throughput/low latency.

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

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

> I must say, this is probably the weirdest and most invalid method
> of attacking another project I've ever seen: the GitHub-generated distribution
> of languages ? Please do not take offence, but I cannot resist laughing while
> writing this; your method of advertising a product it is quite absurd.

dunno, imo it's just an honest, direct and
down-to-earth approach to express project's
stance.  if they disagree, they are free to put
"nsapass" around other unicode characters of their
choice.  the unicode consortium is generous.

i hope all open source projects adopt this style,
and stop being too serious about their apps.
because, imo, many devs or founders kinda act as
if they are some sacred space unicorns, or as if
their apps are "holy".

and, imo, this style is not new.  i think this is
how people in the open source community used to be
decades ago (before people got detached from
reality and started living in another imaginary
dimension with all the needlessly dramatic CoCs.
they probably watched too much twilight).

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

> I am not trying to stifle your freedom of speech, but I am trying to convince
> you that it is important to provide a balanced analysis of previous
> technologies. Doing so will probably significantly aid the development of your
> program, as you can borrow ideas and build upon them.

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.

> As a prominent Gentoo developer once told me, "you do need to take a different
> look at the world". You also need to understand the meaning of "freedom of
> speech", as this is something about which many of the younger generations are
> confused: I am not a Governmental organisation, I am not trying to detain you
> for your views, and your right to freedom of speech does not protect you from
> all critique.

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

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.

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

[Ashley Dixon]

[-- Attachment #1: Type: text/plain, Size: 7022 bytes --]

[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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Jack]

On 7/19/20 10:57 AM, Ashley Dixon 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.]

Perhaps he's just trying to emulate e. e. cummings.

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

[Ashley Dixon]

[-- Attachment #1: Type: text/plain, Size: 618 bytes --]

On Sun, Jul 19, 2020 at 11:08:43AM -0400, Jack wrote:
> On 7/19/20 10:57 AM, Ashley Dixon 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.]
> 
> Perhaps he's just trying to emulate e. e. cummings.

... And in this corner, James Joyce with Finnegans Wake ... ;-)

-- 

Ashley Dixon
suugaku.co.uk

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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Caveman Al Toraboran]

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

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

[Rich Freeman]

On Fri, Jul 17, 2020 at 1:15 AM Caveman Al Toraboran
<toraboracaveman@protonmail.com> wrote:
>
> hi - recently i heard some guys were suffering in
> this list from keepassxc, which reminded me of my
> my own.  so i finally decided to put an end to
> this in 404 lines of py code:
>
>     https://github.com/Al-Caveman/nsapass
>

Probably won't win an obfuscated python contest, but I was amused.

I'll just go ahead and add in that the NSA really should just offer a
data backup service super-cheap.  Chances are they already have a copy
of most of our data, so why not offer a service to allow us to get it
back from them if we lose it?

US residents are basically already paying (through taxes) for a
service to backup all their data.  Why not close the loop and actually
get some personal benefit from having that data returned to them when
they end up needing it?

Since we're generously paying to back up everybody else's data as well
around the world, I guess we could sell the restoration service as a
revenue generator outside the US.

-- 
Rich

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

[james]

On 7/17/20 8:11 AM, Rich Freeman wrote:
> On Fri, Jul 17, 2020 at 1:15 AM Caveman Al Toraboran
> <toraboracaveman@protonmail.com> wrote:
>>
>> hi - recently i heard some guys were suffering in
>> this list from keepassxc, which reminded me of my
>> my own.  so i finally decided to put an end to
>> this in 404 lines of py code:
>>
>>      https://github.com/Al-Caveman/nsapass
>>
> 
> Probably won't win an obfuscated python contest, but I was amused.
> 
> I'll just go ahead and add in that the NSA really should just offer a
> data backup service super-cheap.  Chances are they already have a copy
> of most of our data, so why not offer a service to allow us to get it
> back from them if we lose it?

Never going to happen cause it would validate what everone knows that 
the gov. agencies are collecting up massive amounts of illegal data, via 
large corporations that DO have full access to our privacy and they are 
being paid by the US gov.

> 
> US residents are basically already paying (through taxes) for a
> service to backup all their data.  Why not close the loop and actually
> get some personal benefit from having that data returned to them when
> they end up needing it?
> 
> Since we're generously paying to back up everybody else's data as well
> around the world, I guess we could sell the restoration service as a
> revenue generator outside the US.

Hmmmmm. Nice info. No diagreements, but the issue is much deeper!


I'm a bit more proactive, in thought. So, imho, one day we'll have a 
presidential candidate that postulates constitutional reform: If you 
have no felony convictions, then you have a GOD GIVEN RIGHT to superior 
security than the government AND they must go through a public court 
system process to LEGALLY obtain the right to spy in a given Citizen, in 
good standing.

Own guns and shoot whoever violates the interior of your home, or 
threatens you with bodily harm. Ignore the rest. Wanna block\reform the 
feds?   There is a pathway.

REAL RANDOM and asynchronous multipath (you'll have to figure out the 
second one for yourself....

Not fakes like these DoD posers:

It's lives at http://wheelhorse.io

But the real deal:

RR:     https://www.realrandom.co/wp/

And of course you have to provide/instantiate
Root CA services (another can of worms)....


The FF are scared to death of these guys (RR), cause they are upstanding 
and legally establish. Sure, Rich, a guy like you could do a 
prototye/test, and drop my name on them to get this all for free, for a 
90 day test. I'm too close to them, spiritually, just so you know.


I'm rapidly aging and may not have many more years at the keyboard. Time 
is short, before the great satan takes over our constitutionally given 
rights and guarantees to privacy.


be blessed,
James

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

[Ashley Dixon]

[-- Attachment #1: Type: text/plain, Size: 2315 bytes --]

On Fri, Jul 17, 2020 at 02:46:15PM -0400, james wrote:
> Never going to happen cause it would validate what everone knows that the
> gov. agencies are collecting up massive amounts of illegal data, via large
> corporations that DO have full access to our privacy and they are being paid
> by the US gov.

Surely the devilish corporations would be paying the Government  for  access  to
the data, not the other way around ?

> I'm a bit more proactive, in thought. So, imho, one day we'll have a
> presidential candidate that postulates constitutional reform: If you have no
> felony convictions, then you have a GOD GIVEN RIGHT to superior security
> than the government AND they must go through a public court system process
> to LEGALLY obtain the right to spy in a given Citizen, in good standing.

It sounds like the Presidential Candidate's prospective administration is giving
you these rights, not God. If the Man himself had wanted Americans to have these
rights, why not give them out now ?  Why wait for a new President ? The time for
renewed insanity is now, Brother.

> Own guns and shoot whoever violates the interior of your home, or threatens
> you with bodily harm. Ignore the rest. Wanna block\reform the feds?   There
> is a pathway.

How about the exterior of your home ? I am very protective of my flower beds and
hanging baskets. If some bastard waltzed onto my driveway and touched my hanging
baskets, his dancing career would soon cease.

> REAL RANDOM and asynchronous multipath (you'll have to figure out the second
> one for yourself....

True randomness has already been achieved: just take the next  error  code  that
will be thrown out by any Microsoft product.  I doubt any dirty actors  will  be
able to predict that !

> I'm rapidly aging and may not have many more years at the keyboard. Time is
> short, before the great satan takes over our constitutionally given rights
> and guarantees to privacy.

Hopefully God will choose to act soon.  The change might come faster in cultures
which believe in more than one higher being (e.g., many parts  of  India).   Are
they all equally likely to bring change ?

> be blessed,

I'm a Satanist.

-- 

Ashley Dixon
suugaku.co.uk

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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[J. Roeleveld]

On 17 July 2020 07:15:01 CEST, Caveman Al Toraboran <toraboracaveman@protonmail.com> wrote:
>hi - recently i heard some guys were suffering in
>this list from keepassxc, which reminded me of my
>my own.  so i finally decided to put an end to
>this in 404 lines of py code:
>
>    https://github.com/Al-Caveman/nsapass
>
>hth.
>
>rgrds,
>cm.

Looks nice. Except for:
I like having a GUI where I can easily access the different account details.
Does it use Keepass databases? Or something you designed yourself?
Can it work with password database files that are stored on a central server without having to change the code?
A password database with NSA in the name does not inspire confidence.

--
Joost
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

[Caveman Al Toraboran]

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, July 17, 2020 8:56 PM, J. Roeleveld <joost@antarean.org> wrote:

> Looks nice. Except for:
> I like having a GUI where I can easily access the different account details.

how about:
    `nsapass list | less`
?

(thinking to let nsapass automatically pipe list's
output to `less`)


> Does it use Keepass databases? Or something you designed yourself?

myself.  it's just an encrypted json file.  you
can decrypt it by `scrypt dec path/to/db.enc` to
see how stupidly simple it is.

(to create it, use `nsapass gen 25 printable` to
generate an entry quickly, or `nsapass add UNAME
PWORD NOTE` for a manual approach).


> Can it work with password database files that are stored on a central server without having to change the code?

no.  i personally sync my passwords file with git
(as i also sync my configs).


> A password database with NSA in the name does not inspire confidence.

it's like making a bear gag.  if you run away from
bear, bear may chase you.  but instead if you
stand, and put your fist in bear's mouth, the bear
gags and runs away.

i wonder if this would make nsa gag and run away?
on the other hand, but if it was named
BlockchainedTorPass, they would be probably
sniffing at it day long.

the name is a joke though.  i thought it is funny
(someone suggested it to me and i liked it).

just to clarify, i am not even against nsa.  imo
nsa people are actually good guys that try to
audit suspects to ensure longer stability and
peace, and it's disappointing that they get a bad
image in media.

that said, i just like having a personal space
that its boundaries are respected.  if anyone
wants my data, i want him to take it with my
approval.

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

[Rich Freeman]

On Sat, Jul 18, 2020 at 12:51 PM Caveman Al Toraboran
<toraboracaveman@protonmail.com> wrote:
>
> it's just an encrypted json file.  you
> can decrypt it by `scrypt dec path/to/db.enc` to
> see how stupidly simple it is.

I have to say that this entire thread is a great example of Poe's Law
in action...

-- 
Rich

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

[james]

On 7/18/20 1:03 PM, Rich Freeman wrote:
> On Sat, Jul 18, 2020 at 12:51 PM Caveman Al Toraboran
> <toraboracaveman@protonmail.com> wrote:
>>
>> it's just an encrypted json file.  you
>> can decrypt it by `scrypt dec path/to/db.enc` to
>> see how stupidly simple it is.
> 
> I have to say that this entire thread is a great example of Poe's Law
> in action...
> 

Poe's law is not a law, but conjecture, at best.
Poe's Law is Oxymoronic......

I'll bet Poe's conjecture, will not survive a few generations. 
Scriptures, are recognized by billions of of folks, as authentic, 
regardless of compliance, for thousands of years. Poe is a joke; ymmv.

<snip>


Back to the subject: encryption:

https://www.realrandom.co/wp/

Real Random, is true, random encryption, that the Feds cannot 
compromise, unless the origination/generation is itself corrupt.  D. 
Ritchie wrote an abstract about C and the kernel being compressible, 
from the beginning.


https://www.realrandom.co/wp/

If you really, really want to secure those communications channels. It 
works with most every system, tested so far.

peace my friends,
James

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

[J. Roeleveld]

On Saturday, 18 July 2020 18:51:12 CEST Caveman Al Toraboran wrote:
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> 
> On Friday, July 17, 2020 8:56 PM, J. Roeleveld <joost@antarean.org> wrote:
> > Looks nice. Except for:
> > I like having a GUI where I can easily access the different account
> > details.
> how about:
>     `nsapass list | less`
> ?
> 
> (thinking to let nsapass automatically pipe list's
> output to `less`)

This is not a GUI

> > Does it use Keepass databases? Or something you designed yourself?
> 
> myself.  it's just an encrypted json file.  you
> can decrypt it by `scrypt dec path/to/db.enc` to
> see how stupidly simple it is.
> 
> (to create it, use `nsapass gen 25 printable` to
> generate an entry quickly, or `nsapass add UNAME
> PWORD NOTE` for a manual approach).

This makes portability a problem. Exactly why keepass (and clones) are used 
more.

> > Can it work with password database files that are stored on a central
> > server without having to change the code?
> no.  i personally sync my passwords file with git
> (as i also sync my configs).

Nice, a full detailed list of every single change to your passwords :)

> > A password database with NSA in the name does not inspire confidence.
> 
> it's like making a bear gag.  if you run away from
> bear, bear may chase you.  but instead if you
> stand, and put your fist in bear's mouth, the bear
> gags and runs away.
> 
> i wonder if this would make nsa gag and run away?
> on the other hand, but if it was named
> BlockchainedTorPass, they would be probably
> sniffing at it day long.
> 
> the name is a joke though.  i thought it is funny
> (someone suggested it to me and i liked it).

I do understand it's a joke, but a lot of people won't.

> just to clarify, i am not even against nsa.  imo
> nsa people are actually good guys that try to
> audit suspects to ensure longer stability and
> peace, and it's disappointing that they get a bad
> image in media.

Considering what the NSA (and the other TLAs have been upto), I'm afraid I 
have to disagree with you on this.

> that said, i just like having a personal space
> that its boundaries are respected.  if anyone
> wants my data, i want him to take it with my
> approval.

The likes of NSA don't actually care about your (dis)approval.

--
Joost

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

[Caveman Al Toraboran]

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, July 18, 2020 11:13 PM, J. Roeleveld <joost@antarean.org> wrote:

> This is not a GUI

xterm is GUI.  you don't need to click on gtk/qt
widgets to access details of password entries.
gtk/qt is a massive overkill.

> This makes portability a problem. Exactly why keepass (and clones) are used
> more.

compatibility with keepassxc is extremely
overrated.  it's easy to port nsapass to
windows/apple (may even work out of the box,
didn't try).

> Nice, a full detailed list of every single change to your passwords :)

no.  how do you backup your passwords file?
dropbox?  flash disk?  it's up to you.  this is
unrelated to the passwords manager.

it's just that i personally use git.  that's all.
some use dropbox, and it's the same in this
regard:  none of them see passwords.  they only
get encrypted passwords.

i put encrypted psswords database in a git server.
it's my personal choice.  you don't have to do it.
the git server sees random bytes only.

and thanks to scrypt, even if i don't do anything,
but merely encrypt/decypt with the same key, the
encrypted file will still look totally different.


> The likes of NSA don't actually care about your (dis)approval.

no one does.  not unique to nsa.  people
exaggerate nsa as if they are any better.

tbh, nsa is even better than most of our
neighbours.  if our phones fall in the hands of
our neighbours, next day most people will find
themselves in pornhub.  but nsa can get it all,
and yet they still didn't leak it to pornhub (at
least not as much).

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

[J. Roeleveld]

On Sunday, 19 July 2020 09:48:35 CEST Caveman Al Toraboran wrote:
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> 
> On Saturday, July 18, 2020 11:13 PM, J. Roeleveld <joost@antarean.org> 
wrote:
> > This is not a GUI
> 
> xterm is GUI.  you don't need to click on gtk/qt
> widgets to access details of password entries.
> gtk/qt is a massive overkill.

Please check the meaning of " GUI " and try to answer my statement again.

> > This makes portability a problem. Exactly why keepass (and clones) are
> > used more.
> 
> compatibility with keepassxc is extremely
> overrated.  it's easy to port nsapass to
> windows/apple (may even work out of the box,
> didn't try).

Compatibility with "keepass" (keepassxc is already a different tool/clone) is 
important and makes it simpler to use the same database on different 
environments.
You might be happy with a simplistic database that only stores a few 
passwords. I tend to deal with passwords that are shared within teams because 
the hardware involved only supports a single account. This makes tools like 
keepass important.

> > Nice, a full detailed list of every single change to your passwords :)
> 
> no.  how do you backup your passwords file?
> dropbox?  flash disk?  it's up to you.  this is
> unrelated to the passwords manager.

Actually, the more copies with changes to your passwords there are, the easier 
it will be to guess your passwords.

And no, I do not use dropbox, I use a secure filestore for this.

> > The likes of NSA don't actually care about your (dis)approval.
> 
> no one does.  not unique to nsa.  people
> exaggerate nsa as if they are any better.
> 
> tbh, nsa is even better than most of our
> neighbours.  if our phones fall in the hands of
> our neighbours, next day most people will find
> themselves in pornhub.  but nsa can get it all,
> and yet they still didn't leak it to pornhub (at
> least not as much).

No, they leak it to the press and wikileaks.

--
Joost

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

[Caveman Al Toraboran]

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, August 1, 2020 5:49 PM, J. Roeleveld <joost@antarean.org> wrote:

> > > This is not a GUI
> >
> > xterm is GUI. you don't need to click on gtk/qt
> > widgets to access details of password entries.
> > gtk/qt is a massive overkill.
>
> Please check the meaning of " GUI " and try to answer my statement again.

xterm/urxvt is a gui.  it can render images too.
e.g.  seen ranger?

but nitpick aside, i know what you want.  you want
an app that uses gtk or qt libraries, so that you
get some buttons to click on with your mouse, and
menus and scrollbars to drag around — but why
would you seek to do this to yourself?  very
sadistic.

if you check the latest version in this dev branch
(wip, code will improve next month):

    https://github.com/Al-Caveman/nsapass/tree/space-cephalopod

you'll find a neat interactive feature and a
search feature that allows you to, say, retrieve
passwords really fast.  e.g. `nsapass get c p`
would equate `nsapass get caveman protonmail` (if
c p makes it unique).

> > > This makes portability a problem. Exactly why keepass (and clones) are
> > > used more.
> >
> > compatibility with keepassxc is extremely
> > overrated. it's easy to port nsapass to
> > windows/apple (may even work out of the box,
> > didn't try).
>
> Compatibility with "keepass" (keepassxc is already a different tool/clone) is
> important and makes it simpler to use the same database on different
> environments.
> You might be happy with a simplistic database that only stores a few
> passwords. I tend to deal with passwords that are shared within teams because
> the hardware involved only supports a single account. This makes tools like
> keepass important.

curious, any standardized or special hardware that
works with keepass?  e.g. some kind of dual factor
authentication?  or maybe USB sticks that give you
some physical button to, mechanically, select if
the passwords inside should be read?  anything
else interesting?

about `few passwords'.  i'm also curious why do
you think so?  e.g. here is a quick test with an
outrageously unrealistic test of 1 million key
entries in nsapass:

    - 3.9 seconds for scrypt to decrypt the file.
      for a good reason that makes it more secure
      than keepass's aes 256-bit enc.

    - 2.6 seconds for python's json to parse the
      file (parsing 1 mil entries).

    - everything else was instantaneous after that
      (just a dictionary lookup).

about your team, not sure about your point.  you
said that nsapass is simplistic.  so i guess this
means that keepass offers you something more?  or
is it just that you have more people already using
it and too lazy to migrate?

> > > Nice, a full detailed list of every single change to your passwords :)
> >
> > no. how do you backup your passwords file?
> > dropbox? flash disk? it's up to you. this is
> > unrelated to the passwords manager.
>
> Actually, the more copies with changes to your passwords there are, the easier
> it will be to guess your passwords.

i never denied this.  nothing in nsapass that
makes you copy passwords with changes.  i don't
know where you got this.

i personally use git to copy my passwords database
around, but this -obviously- has nothing to do
with nsapass.

> > > The likes of NSA don't actually care about your (dis)approval.
> >
> > no one does. not unique to nsa. people
> > exaggerate nsa as if they are any better.
> > tbh, nsa is even better than most of our
> > neighbours. if our phones fall in the hands of
> > our neighbours, next day most people will find
> > themselves in pornhub. but nsa can get it all,
> > and yet they still didn't leak it to pornhub (at
> > least not as much).
>
> No, they leak it to the press and wikileaks.

leakers like snowden?  doesn't media call them
``heros''?

see, NSA is made of decent people.  they either
keep our secrets better than our neighbours do,
or, when they leak it, they do so for a good cause
and become ``heros''.

i personally trust NSA much better than my trust
to my neighbours (no comparision).  nothing personal
against my neighbours, decent people, but they are
less educated than NSA's staff.

it's just a matter of honesty to state that media's
stance against NSA is unfair imo.  even though this
statement will probably harm the reputation of
nsapass as i'm its dev and i'm flirting NSA (not
that it matters though).