eb
TheSilentDrifter
eb7246eb8e26b0c48dd4f9c2a822a0f4d5c84138937195090932b61a2d756051

You don't have any evidence to disprove him, so instead you attempt to attack his character? Where did you learn to debate?! Logical fallacies prove nothing! Jack bases his claims off evidence, inviting people to learn for themselves.

How is attestation being performed to prove the integrity of the file? How are you addressing stale file states (file gets removed from one source, but before the deletion is reported to the network, another person downloads it)? Do you have plans to allow sealing the content for specified users?

I would disagree with you opinion of it not being broken. It does work, but it has some painful flaws. If people switch to age, the argument could be reversed as far as popularity.

That is debatable. If there is a proven better solution, then using something brokendoesn't make sense

Neither. This is a weakness in how the JVM responds to invalid memory access. While there are some security issues existing in the LXC namespace, they do not correlated with this issue.

That gets a little complicated. The short answer is yes, but the are not any security measures preventing heap dumps from memory access violations. If your application is on the device, it can cause a dump and grab the info from it.

#rust adherents are deluded in believing the idea that merely memory access violations are the only kind of way in which the security of software is breached

firstly, this only applies to binary code running on physical or virtualized hardware, where a kernel is managing access to memory - it isn't relevant to such runtime environments like WASM or JVM because they already have automatic access controls and generally are not targeted by languages that have pointer arithmetic

secondly, more often the problem comes from poorly constructed access control systems, where simplicity of the code is the key thing to enabling the developers to notice that there is a problem and prevent the code running in the wild to be exploited by hackers looking to breach potentially valuable user data

thus, the more complex and circuitous the language syntax is, the more ways in which it can be made completely idiosyncratic by the use of macro programming, the harder it is to learn the language, ie, the more complex the syntax, the more ways in which errors in ACL systems can be introduced and lead to methods to bypass the ACL and/or privilege escalate to enable read/write access to data that is supposed to be privileged

and lastly, a hard to understand, and difficult to learn memory management system, that prevents the aforementioned buffer overflow attacks, creates a false sense of security for those who make decisions about what language to implement a system with

most of the shitcoins now run smart contracts written in rust, and unless i'm mistaken, the frequency of breaches and hacks has not changed one iota

#fuckrust

The JVM has the String pool. An area of memory which is NEVER garbage collected. It only cleans itself on heap dump or application restarts. Unless you are encrypting client-side, your PII and credentials are stored in plain text in memory. #NoMoreJava