<tankf33der>
what is that Symbol word and where it points on this image from doc?
<Regenaxer>
Hmm
<Regenaxer>
you mean the pointer to the value?
<Regenaxer>
"word" means machine word?
<Regenaxer>
or you mean the word "Symbol" on top?
<Regenaxer>
Same as in the simpler case:
<Regenaxer>
Symbol
<Regenaxer>
|
<Regenaxer>
+-----+-----+
<Regenaxer>
V
<Regenaxer>
| / | VAL |
<Regenaxer>
+-----+-----+
<Regenaxer>
It reads as "a symbol is represented by such a pointer", ie ...xxx1000
<tankf33der>
i meant "Symbol" on top drawn by red marker
<tankf33der>
because there is another symbol "abcdefghijklmno"
<tankf33der>
on right.
<tankf33der>
its like symbol's name and val are different cells, right ?
<Regenaxer>
"abcdefghijklmno" is not a symbol
<tankf33der>
i read:
<tankf33der>
a symbol with the name "abcdefghijklmno" has three properties
<Regenaxer>
in this case they are different cells, yes
<Regenaxer>
right
<Regenaxer>
The name is actually a number internally
<tankf33der>
ok.
<Regenaxer>
and always at the end (may be a single cell if no properties and a short name (up to 7 bytes))
<tankf33der>
i found this in doc, yes.
<Regenaxer>
ok
<Regenaxer>
'onmlkji' is a short number
<Regenaxer>
'hgfedcba' is full 64 bits
<Regenaxer>
+-----+-----+
<Regenaxer>
| DIG | CNT |
<Regenaxer>
+-----+-----+
<Regenaxer>
from doc64/structures in bignum
<tankf33der>
yeap.
<tankf33der>
everybody knows except me:
<tankf33der>
1. (put 'X 'v) delete property
<tankf33der>
2. (prop 'X 'z) creates property z with value NIL
<tankf33der>
right ?
<tankf33der>
documentation doesn cover this side effects.
<Regenaxer>
yeah, this is implicit from the rule that an omitted argument becomes NIL
<Regenaxer>
(put 'X 'v NIL)
<Regenaxer>
And 'prop' and '::' create a cell
<Regenaxer>
(we discussed it here a few days ago with razzy)
<Regenaxer>
(push (:: stack) 7)
<Regenaxer>
s/'prop' and '::' create a cell/'prop' and '::' *guarantee* a cell/
<Regenaxer>
But you are righ, surely not everybody knows that :)
<tankf33der>
maybe add a line to documentation?
<Regenaxer>
I think this is an implementation detail, no?
<Regenaxer>
the 'prop' thing I mean
<Regenaxer>
Omitted arguments to NIL is everywhere
<Regenaxer>
But the prop thing is transparent. 'get' returns NIL both for non-existing properties and for an actually stored NIL
<Regenaxer>
It is just an internal optimization that NIL is not stored (or the property removed for a value of NIL)
xkapastel has joined #picolisp
ubLIX has joined #picolisp
<tankf33der>
i meant:
<tankf33der>
doc says:
<tankf33der>
"Fetches a property for a property key sym from a symbol. ...."
<tankf33der>
it doesnt say:
<tankf33der>
"Fetches a property for a property key sym from a symbol or create *new* with value NIL ..."
<tankf33der>
....
<tankf33der>
"Stores a new value any for a property key sym (or in the symbol value for zero) in a symbol or delete if ....
<tankf33der>
IMO its the same (push1 'L 5) add something to head of the list but you dont want add additional info to doc and says " I think this is an implementation detail, no?"
<tankf33der>
:)
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #picolisp
<Regenaxer>
"create *new* with value NIL" is only internal
<Regenaxer>
For put or get it has the same effect
<tankf33der>
ok then.
<Regenaxer>
I don't want to confuse so much ;)
<Regenaxer>
I think instead of "create" the right term might be "reserve" a cell
<Regenaxer>
But "reserve" is not really a concept of the language
<freemint>
do we have the infrastructure in place that we would notice if Regenaxer's picolisp.tar.gz was compromised?
<Regenaxer>
There is a md5sum
<freemint>
do you publish the md5sums in another way than the webservers?
<freemint>
(which we assumed compromised)
orivej has quit [Ping timeout: 245 seconds]
<Regenaxer>
People (and me) would need to remember it
<Regenaxer>
And watch for changes
yunfan has quit [Quit: already be with hell]
<freemint>
do you see a way how automation could help here?
<Regenaxer>
Have not thought about that
<freemint>
not a high priority but something that needs to be addressed at some time.
<freemint>
do you have thoughts about a "PicoLisp" packet manager?
<freemint>
like npm, PEAR, quicklisp, anaconda, pip, ... what ever
<Regenaxer>
beneroth has some thoughts about a package manager
<tankf33der>
i have a version of blake2sum via mmap.
orivej has joined #picolisp
yunfan has joined #picolisp
freemint has quit [Ping timeout: 246 seconds]
<rick42>
OpenBSD project uses signify (in base) to sign and check downloads. Keys for current version and next version are delivered in base sets; so all you need to do is get any base sets once via a trusted method, then you can follow the chain of "next version" keys. I wonder if we could come up with a similar scheme but using tankf33der's signify instead. Interesante
<rick42>
oh Hi BTW :)
<Regenaxer>
Yeah, hi rick42 :)
<rick42>
sha256 or something like that (md5 is what we have now as Reg said) should be enough as long as the checksums couldn't be fooled with
<rick42>
i've only heard of this, but there is a technique to change bits in a file so that (1) the patch (infiltration code) is preserved while (2) the checksum remains the same as the pre-patch checksum. sneaky. i'm a bit foggy on that though as i never looked into it (just heard about it in passing)
<rick42>
iirc that particular attack was on built/executable code, not sources
<rick42>
anyway over my head, but interesting
<Regenaxer>
T
<rick42>
JC (on the ML) announced that he got the Debian package manager (I guess the picolisp Deb PM) to make emacs intergration "automagic" :)
<rick42>
not sure i agree, but i'm not the PM. this solution doesn't seem to be a good separation of concerns (the concerns being the picolisp install/config and those of emacs and the user's personal config). however, "no harm no foul", as any user can still override those choices via hos own (personal) emacs config.
<rick42>
on another note, that was very nice of the PM to oblige
freemint has joined #picolisp
freemint has quit [Ping timeout: 246 seconds]
aw- has quit [Quit: Leaving.]
aw- has joined #picolisp
aw- has quit [Ping timeout: 246 seconds]
freemint has joined #picolisp
ubLIX has joined #picolisp
<beneroth>
hi all
<Regenaxer>
Hi beneroth
<beneroth>
tankf33der, Regenaxer, I was not really aware of the (prop) side effect, but I also agree with Regenaxer to not stress it this additionally in the documentation. In this situations, a property behaves just as any intern symbol, which is also "created" (in memory) on first use implicitly. that is just the consequence of the picolisp (or standard lisp?) behaviour/assumptions that all symbols "always exist".
<Regenaxer>
Correct
<Regenaxer>
The property cell is here similar
<beneroth>
I hardly ever used prop. I don't find the side-effect surprising, and I agree with Regenaxer that it is an internal/implementation mechanism which a usual user in a usual use case should not care or worry about
<Regenaxer>
yeah, and it is not visible, except if you do 'getl'
<beneroth>
you only need to worry about this either when you want to do some advanced deep optimisations (probably prematurely), or maybe in cases (this might affect tankf33der) where you do crypto and worry about leaking information through side-effects (timing/side-channel attacks) or through information that keeps hanging around without deletion until a proper GC run happened AND the memory got reused
<beneroth>
I think stressing this much in the documentation just makes more "half-knowing" picolispers worry about things they should not worry about
<Regenaxer>
T
<Regenaxer>
I would not say that any info could leak here
<Regenaxer>
It is just NIL stored where it is usually just empty
<beneroth>
for the crypto safety aspect.. I think you could maybe make it securely with picolisp, requiring knowledge of picolisp internal behaviour yes.. or you implement it in C or ASM and know what you are doing instead of picolisp, or even better use a trustworthy library - instead of dealing with that within picolisp, if that level of security/threat matters
<Regenaxer>
So the strange case is rather (put 'A 'a NIL) storing nothing
<Regenaxer>
For such safety aspects gc should probably clear CARs of cells in the free list
<beneroth>
Regenaxer, well I can imagine than under some weird circumstance the difference in "allocating a cell vs. it was there before" might allow a timing attack and leak some internal state of the application which might tell the attacker something. it cannot be ruled out 100% generally. but this is extremely specific to the actual use case, actual code, actual whatnot and actual threat model.
<beneroth>
Regenaxer, I, that would be the second aspect I meant before. exactly!
<beneroth>
but for normal usage this is needless overhead
<Regenaxer>
I think such considerations (timing attack) can't be applied here
<beneroth>
better just wrap a C library (or write one using pil asm as picolisp shared library) if you deal with such things (and you really have a threat on that level you need/want to defend against)
<Regenaxer>
and prop is predictable here
<Regenaxer>
just like any other function
<Regenaxer>
Well, you can easily overwrite sensitive data
<Regenaxer>
(mapc set Lst)
<Regenaxer>
before it gets garbage
<beneroth>
T. you can likely implement in picolisp in a way that timing attack does not matter. the point is we cannot rule out the vulnerability to a timing attack in the general case, because such things are extremely extremely highly specific to an actual implementation and implementation details.
<Regenaxer>
Anyway not anything having to do with prop
<beneroth>
T
<Regenaxer>
Timing in pil is more difficult to analyse and abuse than in C
<beneroth>
probably. more state involved.
<Regenaxer>
yes
<beneroth>
so more noise :)
<Regenaxer>
and more machine instructions per operation
<Regenaxer>
yes
<beneroth>
but I also think this probably only matters for pilOS. maybe for server implementations if the programmer does it too naively/stupid, but rather unlikely.
<beneroth>
if you really need to do that, you should be able to afford to do it properly and test it properly and completely
<Regenaxer>
Such timing attacks work well on primitiv[ hardware
<beneroth>
else don't invent shit yourself.
<Regenaxer>
cards
<beneroth>
you mean like the beloved rock64 ? :D
<beneroth>
good point
<Regenaxer>
yes, single "process"es
<beneroth>
(though it has no level 3 cache, so no spectre attack surface)
<beneroth>
you are speaking about client->server attack from outside, not on same physical machine :)
<Regenaxer>
No, monitoring hardware with oszilloscope and logic analyzer
<Regenaxer>
On a server with many processes running it is much more difficult to analyze
<beneroth>
freemint, yeah maybe Regenaxer should move from md5 to something like sha256 which cannot be maliciously faked (for file comparison without a malicious attacker, md5 is still perfect)
<beneroth>
Regenaxer, ah T. but well afaik the trick is to clock such hardware down with low power input or so, low enough so you get enough time to attack. thats how they hacked the nintendo switch console afaik.
<Regenaxer>
I thought about switching from md5, but it is all in that format now
<beneroth>
Regenaxer, that is a bad excuse which makes you sound like a lousy php dev who used md5 for password hashing (for which it was never meant to be used)
<beneroth>
:P
<Regenaxer>
The weak link is not that
<Regenaxer>
it is the server software-lab.de
<beneroth>
no, its only a measurement to DETECT after something bad happened
<beneroth>
right
<Regenaxer>
The ops at strato can fiddle with it
<beneroth>
that is what happened to that pear php repo: repo server got under attacker control
<Regenaxer>
then another hash doesn't help
<beneroth>
if you make the hash on your development machine and publish it by another means than the website, then it would help
<freemint>
so much text
<Regenaxer>
BTW, the releases for Debian I send to Kanru always with PGP signature
<beneroth>
good!
<beneroth>
that is the proper way!
<beneroth>
that is what I see as a requirement for a real package manager: every package signed by developer, and I would say additionally by a repo/distributor. so you can trace the source of an infection (or buggy software) back to where it got introduced. and then you can do whitelisting/blacklisting according to reputation and network of trust.
<beneroth>
freemint, I mentioned you only in the texts which you spoke about earlier. the discussion before that is another topic
<Regenaxer>
bbl
<freemint>
.. have a nice time
<beneroth>
cu Regenaxer :)
<Regenaxer>
:)
<freemint>
beneroth Regenaxer signed releases with key not stored on software-lab.de might help
<beneroth>
now to rick42 lol I initially understood that the problem actually is that debian package DOES set automatically install the picolisp-mode on an emacs installation if it founds one. so now... this got added?
<beneroth>
freemint, what are you talking about now? key?
<beneroth>
which key? are you mixing up hashes and keys?
<freemint>
PGP key.
<freemint>
signed hash of file
<beneroth>
you wanna tell me Regenaxer has his private key stored on software-lab.de? or what?
<beneroth>
link?
<beneroth>
do you know what you are talking about? sorry that I ask, but I'm confused by your wording
<beneroth>
md5 hash is a checksum of the file, has nothing to do with PGP nor signing.
<beneroth>
signing happens with a private key which should be kept secret (private, as the name says), so usually on the devs personal (hopefully secure) machine, or even on a specially secured signing machine, or on a hardware token whatnot. you sign the files in a secure environment. then you publish the files, and you publish the public key. people should get the public key on a secure channel - so either by personally meeting in meat space (real life) or by havin
<beneroth>
g the public key available through multiple channels which are unlikely to be all under the control of an attacker. then you can check the received files with the public key - it only fits if related private key was used to sign the files (or if the signature algorithm got broken, either because it has a weakness or because of (currently) unrealistic more computation power)
<beneroth>
freemint ?
<freemint>
no i said the key should not be stored at the server which i used to distribute the packages - as a general rule
<beneroth>
well Regenaxer, beside attacking the server, the transfer between the server and the client is also an attack vector. either by downloading via HTTP (instead of HTTPS, possible) or by intercepting HTTPS (needs support by a malicious cert authority). against this, the hash published on the website (even when its the same as the one with the download) protects. but with md5 is possible (difficult but possible) to change the file in a way that results in the
<beneroth>
same hash.
<beneroth>
freemint, yes, and Regenaxer surely knows this and we have no reason to believe that he stores his private key on the server
<beneroth>
the hash on the same server is not an issue, as I just wrote. its just not a meaningful help really.
<freemint>
my reasoning for providing signed hashes is that the hash can not be replaced by another one.
<beneroth>
yes, but if you do the effort to sign the hashes, then you can just also sign the real files.
<beneroth>
no gain by the hashes then, I think.
<beneroth>
so yes, to be real, hashes are not much use here, real signatures would the best thing.
<freemint>
but choosing something stronger than md5 is a good idea
<beneroth>
to defend against what?
<beneroth>
I think both md5 and another strong hash is meaningless - unless the hash is also distributed through a secure channel. which it isn't really.
<freemint>
when you sign a file with pgp you actually sign a hash of the file, if i recall correctly
<beneroth>
possible.
<beneroth>
I don't know. tankf33der probably knows. irrelevant for our discussion I think.
<freemint>
i do not get what you are confused about
<freemint>
publishing a hash on one channel does not add security when the file is transmitted via the same channel
<freemint>
when the hash is transmitted over multiple independent channels it adds security.
<beneroth>
aye
<beneroth>
so what do you defend against? compromised server? ok, it might help if Regenaxer would publish the hash also on twitter and mailing list etc., and use something stronger than md5
<beneroth>
defend against attack on network during download? no chance, the attacker can also modify the hash when you download (view) it on this network.
<freemint>
(unless the hash is signed by Regenaxers public key we (could) all have)
<beneroth>
then Regenaxer can sign the files directly, so you can check them directly, instead of making a hash and then check it.
<beneroth>
yes PGP internally probably does the same. but still then - why do it twice (two hashes, the internal one in the pgp and the checksum hash one published) ?
<freemint>
beneroth But nobody sign files directly.
<freemint>
every signs a hash
<beneroth>
why not? aw just did with his email job message
<freemint>
(technically speaking)
<beneroth>
Regenaxer does when he sends the files to debian for packaging.
<beneroth>
yes, but what you propose is technically speaking making a hash of a hash and then sign it
<freemint>
no i do not
<beneroth>
sign files (which technically is the signing of a hash of the files) vs. signing a hash (which is technically signing the hash of the hash), no ?
<freemint>
My "signing hash of file" = your "signing file"
<beneroth>
why don't you call it "signing the file" then? doesn't matter that in implementation to do this another has is built.
<beneroth>
because yes there are people that sign hashes they made of files. two steps. I don't get the meaning of it, I believe its cargo culting. I might be wrong, tell me if so.
<freemint>
beneroth because if you "sign a file" you are still vulnerable to problems with hash function not mentioned in your abstraction
<beneroth>
no I would say I'm not, because the PGP people and implementation takes care of using a proper hash algorithm, I don't have to specify this as an argument.
<beneroth>
pgp certainly does not use md5 internally for making the hash it needs, right?
<freemint>
no but F.e sha1 which is brocken (Although less brocken)
<freemint>
there are collision attacks on sha1
<freemint>
so depending on how you want use pgp, your "pgp does everything good enough, so i do not need to talk about having" assumption is broken
<freemint>
everything clear beneroth?
<beneroth>
so you tell me there are current versions of gpg around which use sha1?
<freemint>
there are versions of gpg around which use sha1
<beneroth>
for the fingerprint
<beneroth>
which is kind of the checksum hash of the public key you got
<beneroth>
so meet in meat space, exchange the public key, no need for even checking with the fingerprint
<freemint>
i am sure it is no longer a default option in the current configs ship with sha1. But you got to check that you do not use a badly configured gpg instance.
<freemint>
do you know how public key crypto work?
<beneroth>
I see
<beneroth>
but your initial "Regenaxer signed releases with key not stored on software-lab.de might help" could be understood as you blaming Regenaxer for storing his private key on the server. you agree?
<freemint>
yes
<beneroth>
aye. and that accusation is just plain wrong and fake news, unless you have some more arguments to support that accusation I would say.
<freemint>
Regenaxer signed releases (with key not stored on software-lab.de ofc ;)) might help"
<freemint>
expresses my intent better
<freemint>
it is some an accusation of you understood the message wrong (philosophigcal tangent)
<beneroth>
you are aware, that when you write such things, it could have the effect that some people passively reading here, or someone finding the chat log much time later when googling for "picolisp release pgp" or so, might get the impression that freemint thinks that Regenaxer works insecurely and that picolisp distro is not to be trusted, aye?
<beneroth>
well my misunderstanding was not deliberate but factual. as I know you, I suspected you mean something else, but that is how it sounded to me, and I don't think I over-interpreted stuff here tbh.
<freemint>
beneroth i do agree that it is misleading in the future when things are shined already.
razzy has joined #picolisp
<beneroth>
it is also misleading now.
<beneroth>
you accuse Regenaxer of bad work habits.
<beneroth>
but yeah, no worries. just try to formulate better :)
<freemint>
as the releases are not yet signed it is impossible for him to store the relevant keys on his server :@
<beneroth>
and I learned a bit about PGP I was not aware before, thanks :)
<beneroth>
as he wrote, the releases he pushes to debian are signed.
<freemint>
beneroth my key point is you perform the crypto which attributes owner ship not on the data itself but on the hash of the data.
<beneroth>
so if you want signed picolisp, get it from debian. just bad that they just this week had to update apt and that you should change all URLs in source.list to https if you want the debian install channel to be trustworthy :P
<freemint>
the last part is bullshit
<beneroth>
how so?
<freemint>
there is nothing https provides for apt
<beneroth>
explain me how
<beneroth>
when the signatures are also downloaded via http ?
<freemint>
what benefit do you think https brings?
<beneroth>
transport security. and some privacy.
<freemint>
no privacy benefits as files can be quiet uniquely identified by transfered size even when encrypted.
<beneroth>
T, though its harder. but good point, granted.
<beneroth>
yes, that mechanism failed in this case, there was a way to trick the signature check.
<freemint>
mhh so he tricked apt into adding a new key during the installation.
<freemint>
(during the preparation of the transportation to be exact)
<freemint>
this attack can also happen via https, the only difference is that you would need to point to a malicious mirror server
<freemint>
(as far as i understand)
<beneroth>
aye, I understood it the same
<beneroth>
though this is arguably a big difference, but yeah.
<beneroth>
I think generally network is probably easier to attack than such a server.
<beneroth>
e.g. DNS poisoning, as you cannot detect the bad mitm/server without https
<freemint>
beneroth one important thing about public private key encryption
<beneroth>
yeah?
<freemint>
most private key encryption looks like that: (% (** private_key data) prime)
<freemint>
when you make data just a bit longer the execution time gets way bigger
<beneroth>
afaik data is often a key for symmetric encryption (e.g. in TLS), which is then used to encrypt the real content data. I don't know if PGP is similar or if it doesn't involve a symmetric key.
<freemint>
signing is really just "encrypting with the private key so the public key can encrypt it"
<beneroth>
and afaik symmetric encryption would also be safe from quantum computers (or other kind of massive paralleled brute force attacks), but not asymmetric encryption, right?
<freemint>
you generate a key pair, and each key could technically be used as either public or private key.
<beneroth>
yeah I know
<freemint>
to sign a message what actually happens it you send (encrypt public-key (hash data))
<freemint>
you check via (= (hash recieved_data) (decrypt public-key signature))
<beneroth>
yes makes sense.
<beneroth>
but still, technical internal detail which should not matter of normal use, ideally. agreed?
<beneroth>
s/of/for
<freemint>
that means if hash is weak for collisions (like sha1 is) that means you can not be sure that data is untouched.
<freemint>
for general software "technical details should not matter" i agree
<freemint>
but for cryptography i absolutely disagree.
<beneroth>
they should not matter. I think its a failure by the software providers if it does matter.
<freemint>
ideally apt should not be able to be made to add untrusted Keys from remotely
<beneroth>
this
<beneroth>
and 7zip should use proper randomness for initializing their AES256
<beneroth>
and OS and hardware should be trustworthy
<freemint>
but because it is cryptography and there maybe lives on the line at some point in the future you absolutely must trust your stack and verify as much as you can bear.
<beneroth>
and all this mess should be easy to use and hard to be used wrongly
<beneroth>
well, always start with threat modelling.
<beneroth>
you cannot defend against everything, so think a bit about what you want to defend against, what plausible attacks now or in future might be
<freemint>
the 0th step should be: try to design your system so it is as nearly impossible to screw up as possible
<beneroth>
T
<freemint>
(under your constraint resources)
<beneroth>
therefore I say its a failure by the PGP software devs if they make vulnerable hashing algorithm available in their software
<beneroth>
therefore I say it SHOULD not matter
<freemint>
mhh but maybe the dev are not at fault and somebody modified your config on your end?
<beneroth>
because the only other way do to this properly is A) don't use computing etc. B) share keys in meatspace and then do all computing on your own built hardware with your complete selfmade software, in Forth or whatever
<freemint>
gpg gives you enough rope to hang yourself
<beneroth>
yes, thats the fault...to much rope given
<beneroth>
don't make insecure configurations possible
<freemint>
not really because it is still needed in some usecases.
<freemint>
any config insecure.
<beneroth>
yes there might be good reasons for such things in practical real use, I'm aware
<freemint>
(absolutly speaking)
<beneroth>
but also maybe you could put this in another separate edition of your software specially made for that purposes?
<beneroth>
needs some documentation and needs an automatic build set up once.
<freemint>
it is a question where you draw some line
<beneroth>
yep
<beneroth>
and I draw the line more on the secure side than the guys who support known insecure hashes in their software... but I'm not drawing the line on the extreme end where you craft your own hardware
<freemint>
that might be a good idea but then, checking the config is more secure than delegating everyones trust too a few devs. (assuming you know what you do)
<beneroth>
yes, that assumption is the big issue in practice usually :)
<freemint>
when you say "give me and everyone a secure versions" you are saying "let's all trust one guy, so we do not need to know what we would need to know to check what he is doing"
<beneroth>
in reality, you do this + user has to make the config secure
<beneroth>
if we reduce it to the issue with trusting that one guy, we reduced something
<beneroth>
yes it should be FOSS and we should build ourselves and ideally also look into the source. like the guy recently did with 7zip, everyone else just trusted the guy, and the guy made horrible mistakes.
<beneroth>
you might be in nice academic setting, freemint
<beneroth>
in reality, a big big crowd of software devs use NPM, which has not even signatures and proofed 3 times so far that the repo operators do not manage the repository in a way that it is safe from malicious code placed on the repo.
<beneroth>
in reality, your business manager will you never give the time to do stuff secure and properly
<beneroth>
in reality, nobody cares until something bad happens.
<beneroth>
:(
<freemint>
some people obviously care before something bad happens. Otherwise 7zip would not have been found
<beneroth>
yep. and thats possible thanks to FOSS. thanks RMS.
<freemint>
I do not see what role RMS had in this FOSS is an obvious construct.
<beneroth>
he started the whole thing
<beneroth>
it might be obvious now.
<freemint>
i do not think Stallman was involved in making the original UNIX source code open source.
<beneroth>
well you might call the "free sharing of source code between people working at different universities and companies" which was the case with UNIX in the beginning "open source", but that sharing was made without any license or legal rights consideration. the rights of the respective code parts belonged to the related university/private company.
<beneroth>
he quit his job, and started implement GCC and emacs and re-implement a lot of standard unix stuff, to properly licensee it for FOSS.
<beneroth>
yes, he lived in that days, and as this ended he started FOSS movement to keep this alive.
<freemint>
he did good stuff but i would hail him as person without him we would not have OSS
<beneroth>
maybe someone else would have done eventually. but that you can say about anyone.
<freemint>
also TeX is FOSS and existed before gnu
<beneroth>
I personally have much respect for people who think about such things, and then decide to take on great personal risks to follow their principles and values and actually do something.
<beneroth>
most people don't think about it. some people think about it and then do nothing.
<beneroth>
I admire people who are consequent.
<beneroth>
and I find that it is a difference if you "just" tried something out and happened to be lucky, or if you deliberated thought about it, saw the risk and consequences, and attempted it anyway.
<beneroth>
and I don't think you can dispute that he made it way easier for other people to also make FOSS.
<beneroth>
whatever you may think of his current actions and behaviours.
razzy has quit [Read error: Connection reset by peer]
<freemint>
he made it easier for other persons to make FOSS
alexshendi has joined #picolisp
<Regenaxer>
ret
<Regenaxer>
wow, long discussions tldr ;)
<beneroth>
not relevant for you :)
<Regenaxer>
ok :)
<Regenaxer>
BTW, my public key is on software-lab.de since decade(s)
<beneroth>
yes, but not the private one, I guess ;-)
<Regenaxer>
of course
<beneroth>
why don't you just remove the md5 hashes on the download page? I think they serve no purpose, unless you believe that transfer errors are still a thing.
<Regenaxer>
true
<Regenaxer>
Nobody would complain?
<beneroth>
no idea. you can find out. somebody always complains, no? https://xkcd.com/1172/
<Regenaxer>
yep
<beneroth>
and freemint points out that one should check if one uses a good hashing algorithm when using pgp
<beneroth>
I hope the software as sane defaults :)
<Regenaxer>
I use mutt's gpg
<rick42>
beneroth: yes, picolisp-mode was already added to the emacs "tree" (under site-lisp) but it wasn't getting autoloaded or somthing like that (there was just one more step). the next iteration/revision will have "automagic" :)
<rick42>
that's what JC meant by making picolisp-mode "visible" in Debian (after one package-installs emacs and picolisp)
<beneroth>
rick42, I experienced the whole discussion as being about a rather small and unimportant issue.
<rick42>
it really still is. just funny to me
<rick42>
:)
<beneroth>
the big point, about merging the different emacs modes with different weaknesses into one without weaknesses was a good big point, but I don't think anyone is willing to really take care of that for now.
<beneroth>
(including me)
<rick42>
yeah, that's a bigger job
<beneroth>
eventually I will take care of this, or switch to vip, I guess. I love paredit, so maybe I would like to add something like it to vip. dunno.
<beneroth>
for now the pain is not big enough for me to change anything, and I got work to do :)
<rick42>
it was nice to see that Alexia was very willing to work with you, beneroth, on paredit issues
<beneroth>
T
<rick42>
Alexis
<beneroth>
absolutely
<rick42>
(I feminized him with my terrible typing skillz :)
<rick42>
beneroth: i totally agree with the PITA and having work to do (and no time)