Re: [gentoo-user] nsapass - alternative to keepassxc (and others)
‐‐‐ Original Message ‐‐‐ On Sunday, July 19, 2020 6:57 PM, 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.] 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.
Re: [gentoo-user] Local mail server
On 7/19/20 8:18 AM, Peter Humphrey wrote: Afternoon all, Hi, I'd like to set up a little box to be a local mail server. It would receive mails from other machines on the LAN, and it would fetch POP3 mail from my ISP and IMAP mail from google mail. KMail on my workstation would then read the mails via IMAP. That's all. I might want to add a few extras later, such as receiving SMTP mail for a .me domain I own. My present total of emails is about 4000. That should be quite possible to do. IMHO there's not much difference in an internal only and an externally accessible mail server as far as the software & configuration that's on said server. The only real difference is what the world thinks of it. I used to have a working system on a box that's now deceased [1], but in replicating it I'm having difficulty threading my way through the mutually inconsistent Gentoo mail server docs, omitting the bits I don't need and interpreting the rest. Bits I don't need? Database backend, web-mail access, web admin tools, fancy multi-user authorisation, any other baroque complexity. There are a LOT of ways to do this. You need to pick the program that you want to use for various functions: - SMTP: Sendmail (my preference), Postfix (quite popular), etc. - IMAP: Courier (my preference), Dovecot (quite popular), etc. - POP3: Courier, Dovecot (?), QPopper (?), etc. - LDA: Procmail (my preference), delivermail, etc. Pick the programs that you want to run, possibly influenced by what they do and don't support to find an overlap that works. E.g. Maildir used to be less well supported than it is today. You have already indicated that you want to use fetchmail (or something like it). So I'm asking what systems other people use. I can't be unusual in what I want, so there must be lots of solutions out there somewhere. Would anyone like to offer me some advice? I actually think it's more unusual to want to run an email server that doesn't receive email directly from the world vs one that does. But whatever you want. As others have alluded to, sending email may be tricky, but ultimately possible to do. It will have a LOT to do with what domain name you use, and if you have your server smart host through something else. 1. Yes, of course I did have backups, but in juggling the media I managed to lose them. A world of advice to others: don't grow old. :) Oops! -- Grant. . . . unix || die
Re: [gentoo-user] Local mail server
Am Sonntag, 19. Juli 2020, 16:18:32 CEST schrieb Peter Humphrey: > Afternoon all, > > I'd like to set up a little box to be a local mail server. It would receive > mails from other machines on the LAN, and it would fetch POP3 mail from my > ISP and IMAP mail from google mail. For me this was a good starting point: https://wiki.gentoo.org/wiki/Complete_Virtual_Mail_Server[1] I placed a Gentoo VM for this on my Proxmox VM server doing the job. regards Petric [1] https://wiki.gentoo.org/wiki/Complete_Virtual_Mail_Server
Re: [gentoo-user] Local mail server
Dovecot works well enough, catch is that it has some security issues. My fix is to have it run on localhost and ssh tunnel local ports into 143 & 25 on the in-house server. At that point postfix + dovecot work fine for me. -- Steven Lembark Workhorse Computing lemb...@wrkhors.com +1 888 359 3508
Re: [gentoo-user] Local mail server
On Sunday, 19 July 2020 16:48:29 BST antlists wrote: > On 19/07/2020 15:18, Peter Humphrey wrote: > > So I'm asking what systems other people use. I can't be unusual in what I > > want, so there must be lots of solutions out there somewhere. Would anyone > > like to offer me some advice? > > Doing my best to remember my setup ... > > Running postfix as my mail server. I never managed to get it working to > SEND email, so clients had to be configured to send straight to my ISP. > Don't send to google - it rewrites the headers ... > > Used fetchmail to download, until an upgrade/fix/something broke MySQL > so all my virtual email addresses broke. > > Use Courier-IMAP to provide access from clients to the mail store. > > I *think* that's all, but I dunno how long my system has been running > (it hasn't even been updated for a couple of years :-( and apart from > that MySQL problem it's been running untouched pretty much from day 1. > > Cheers, > Wol Notwithstanding a recent security vulnerability net-mail/dovecot may be able to do all you want/need from a home mailserver. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Local mail server
On 19/07/2020 15:18, Peter Humphrey wrote: So I'm asking what systems other people use. I can't be unusual in what I want, so there must be lots of solutions out there somewhere. Would anyone like to offer me some advice? Doing my best to remember my setup ... Running postfix as my mail server. I never managed to get it working to SEND email, so clients had to be configured to send straight to my ISP. Don't send to google - it rewrites the headers ... Used fetchmail to download, until an upgrade/fix/something broke MySQL so all my virtual email addresses broke. Use Courier-IMAP to provide access from clients to the mail store. I *think* that's all, but I dunno how long my system has been running (it hasn't even been updated for a couple of years :-( and apart from that MySQL problem it's been running untouched pretty much from day 1. Cheers, Wol
Re: OT: Re: [gentoo-user] nsapass - alternative to keepassxc (and others)
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 signature.asc Description: PGP signature
OT: Re: [gentoo-user] nsapass - alternative to keepassxc (and others)
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: [gentoo-user] nsapass - alternative to keepassxc (and others)
[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 +, 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. > >
[gentoo-user] Local mail server
Afternoon all, I'd like to set up a little box to be a local mail server. It would receive mails from other machines on the LAN, and it would fetch POP3 mail from my ISP and IMAP mail from google mail. KMail on my workstation would then read the mails via IMAP. That's all. I might want to add a few extras later, such as receiving SMTP mail for a .me domain I own. My present total of emails is about 4000. I used to have a working system on a box that's now deceased [1], but in replicating it I'm having difficulty threading my way through the mutually inconsistent Gentoo mail server docs, omitting the bits I don't need and interpreting the rest. Bits I don't need? Database backend, web-mail access, web admin tools, fancy multi-user authorisation, any other baroque complexity. So I'm asking what systems other people use. I can't be unusual in what I want, so there must be lots of solutions out there somewhere. Would anyone like to offer me some advice? 1. Yes, of course I did have backups, but in juggling the media I managed to lose them. A world of advice to others: don't grow old. :) -- Regards, Peter.
Re: [gentoo-user] nsapass - alternative to keepassxc (and others)
‐‐‐ Original Message ‐‐‐ On Saturday, July 18, 2020 11:13 PM, J. Roeleveld 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)
‐‐‐ Original Message ‐‐‐ On Saturday, July 18, 2020 10:28 PM, Ashley Dixon 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
