On Tue, Aug 11, 2015 at 6:58 PM, Sean McArthur
wrote:
> Yes I know. Even just adding `Unofficial' in the description of those
> lists would help prevent confusion, I think.
>
To me "Rustaceans" implies unofficial/community organized, all the way down
to F
ral Rust discussion email list (e.g.
rust-talk), I'd subscribe
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
ers who are used to being able to see the structure of threaded
conversations would get annoyed, as Discourse publishes a flat message
list.
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
ta
dependent timings give attackers a useful statistical signal in Rust crypto
applications, even ones where the core is assembly. I am working on a
library for measuring this empirically.
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozil
st for proving properties about Rust programs using
things like dependent types, refinement types, or otherwise.
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
scrutiny before they should be used for anything serious.
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
monstrates
>> over-the-network AES key recovery using cache timing sidechannels in
>> OpenSSL:
>>
>> http://cr.yp.to/antiforgery/cachetiming-20050414.pdf
>>
>> Things get worse when you're talking about two VMs that are cotenant on
>> the same hyperv
bout two VMs that are cotenant on the
same hypervisor, or shared hosting systems in general.
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
: crypto.rs
> <https://github.com/seb-m/crypto.rs> and Curve41417.rs
> <https://github.com/seb-m/curve41417.rs>, which seem rather interesting
> to me.
Yes, although they are, again lacking constant time primitives to build on.
--
Tony Arcieri
On Mon, Sep 29, 2014 at 10:50 PM, Daniel Micay
wrote:
> MemoryMap doesn't support controlling memory protections.
Will it ever, or is the recommended approach to brew your own
MemoryMap-alike like SBuf is presently doing?
___
Rust-dev mailing list
Rus
Sidebar on SBuf: I'd be curious how it could be written completely in terms
of MemoryMap, or if MemoryMap needs to be extended to support mprotect() /
VirtualProtect().
On Mon, Sep 29, 2014 at 10:39 PM, Tony Arcieri wrote:
> I've been trying to keep an eye on what's been b
does no memory
protections around keying material or internal cipher state.
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
rd the response"
It also provides a typed description language for messages that maps nicely
to Rust's type system.
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
d data in
secure strings. There are many systems today in which this would be an
error.
I can totally understand omitting these sorts of things until there is a
formal correctness check in the complier. At the same time, these are the
sorts of cases I fee
failure to sanitize input, affecting vulnerabilities like XSS, SQLi, and
LDAP injection.
I am absolutely certain this affects systems like Servo as well ;)
Preventing untrusted data from penetrating the secure contexts of the
program using the type system has the potential to mitigate the most co
know
you already have enough work on your plate as-is.
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
any sort of templating would be a lot more
interesting. Maybe in Rust 9.0 ;)
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Rust doesn’t really provide any specific features for security beyond
> memory safety, but it should be possible to extend the language to support
> things like information-flow security, etc.
Yeah, the paper I linked describes using dependent types to do what is
effectively taint checking
et it,
gotta ship 1.0 before anyone gets a pony? ;)
On Sun, Sep 21, 2014 at 1:41 AM, Tony Arcieri wrote:
> I'd also note: having a way of calling out these sorts of cases explicitly
> is enormously beneficial to code reviewers. It provides an easily greppable
> way to find where to fo
39 AM, Tony Arcieri wrote:
> On Sun, Sep 21, 2014 at 1:34 AM, Daniel Micay
> wrote:
>
>> It's not possible to represent the semantics of 'insecure' in the
>> language as
>> that's very poorly defined and varies across domains and libraries.
>
>
&g
On Sun, Sep 21, 2014 at 1:34 AM, Daniel Micay wrote:
> It's not possible to represent the semantics of 'insecure' in the
> language as
> that's very poorly defined and varies across domains and libraries.
I'd define it as "think
ut not necessarily from a memory safety
standpoint?
I think something like that would be pretty cool. "insecure" ? ;)
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
On Fri, Jul 11, 2014 at 11:49 AM, Aaron Turon wrote:
> The best part: approved guidelines can turn into (1) new github issues to
> bring libstd into line and (2) an authoritative way to resolve debates on
> libstd PRs.
How about a gofmt-like source code reformatting utility?
--
Ton
providing I/O "as a service" by having a dedicated task (or pool
of tasks) that performs I/O operations for you, sending completions back as
messages over the normal std::comm message protocol, ala Erlang's ioserver.
Perhaps it's relevant to bring up again?
-- Forwarded message
ogrammer thinks can be avoided will be avoided.
I know you're not fans of a compiler flag, but a checked debug build with
traps you can optimize out in an optimized build could've caught it.
As it were, this is what Swift provides (in addition to explicit overf
Thought I'd just throw this one on the fire ;)
http://blog.securitymouse.com/2014/06/raising-lazarus-20-year-old-bug-that.html
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
On Mon, Jun 23, 2014 at 3:08 PM, Tony Arcieri wrote:
> To flip the question around: what's wrong with Swift's approach?
>
Or perhaps to ask a less pointed question, what's wrong with Swift's
approach besides making the slow operators the
izations.
>
To flip the question around: what's wrong with Swift's approach?
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
works today, besides adding new functionality. I'm
just proposing that the new functionality mirror what Swift is doing, so
that optimizations that are added to LLVM by Apple/Swift can be leveraged
by Rust too.
Make sense?
--
Tony Arcieri
___
Rust-
O Mon, Jun 23, 2014 at 2:08 PM, Tony Arcieri wrote:
> Want to perform well at TIOBE or other (micro)benchmarks? Use the overflow
> operators!
>
I meant http://shootout.alioth.debian.org here, but yeah, I hope you get
the idea ;)
--
Ton
rflow being the default.
If the Rust developers insist on choosing overflow operators as the One
True Way To Do Math, well, that's your prerogative. I will probably still
choose Rust over Swift. But then I feel like Rust might be missing out on
the free lunch I expect Swift to
antics, and Apple
were to submit its LLVM optimizations for this upstream, I feel like Rust
could reap many of the benefits too.
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
PUs may make fast),
and provide a secondary mechanism to get the "unsafe" fast path?
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
t Rust provides as a baseline today would be
obsolete and broken. In the distant future. But still...
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
ked
operations or otherwise desire overflow behavior:
https://developer.apple.com/library/prerelease/ios/documentation/swift/conceptual/swift_programming_language/AdvancedOperators.html#//apple_ref/doc/uid/TP40014097-CH27-XID_37
--
Tony Arcieri
___
Rust-dev mailing
love to see organizations who use Rust (*wink* *wink* *nudge*
*nudge* Mozilla) contribute to and help fund professional security audits
like rust-crypto! :D
Sidebar: I am also working on a Rust crypto library (ClearCrypt) but its
goals are somewhat orthogonal to the needs
tml#//apple_ref/doc/uid/TP40014097-CH27-XID_37
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
You might want to check out this thread... Mozilla is sponsoring work on a
new Rust package manager called Cargo:
https://mail.mozilla.org/pipermail/rust-dev/2014-March/009090.html
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https
lower hanging fruit, how about a standard way to MemoryMap an mlocked
buffer with guard pages that are PROT_NONE?
I've been working on a "SecretBuffer" type for my library ClearCrypt, but
I'd really like to see something like that in Rust pro
cipher planned is ChaCha20.
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
these goals. Every commit will
be approved by multiple people once it has been thoroughly audited.
First up: the choice of a license:
https://github.com/clearcrypt/clearcrypt/pull/1
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
think Rust is doing something that's close to what I'd consider to be
the right thing.
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
e painful failure mode as Ruby (transcoding
blowing up at completely unexpected times) with even more complexity,
making it even harder to debug.
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
t not
another, in which case the transcoding will fail, and it will fail at
runtime.
This can happen long after a string has crossed the I/O boundary. The
result is errors which pop up at runtime in odd circumstances. This is
nothing short of a fucking nightmare to debug.
--
Tony Arcieri
___
d no! Please no. This is what Ruby does and it's a complete nightmare.
This creates an entire new class of bug when operations are performed on
strings with incompatible encodings. It's an entire class of bug that
simply doesn't exist if you just pick a standard encoding and
y
security auditors, preferably by multiple, independent auditors.
Having crypto in the standard library limits agility around shipping
security updates, since now you must update the entire standard library,
and not just one library.
--
Tony Arcieri
about Ken Thompsonesque backdoors? ;)
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
an oxymoron.
>
>
> On 03/28/2014 08:12 PM, Tony Arcieri wrote:
>
>> I really love the semantics of the safe subset of Rust.
>>
>> Recently there has been a call to introduce an optional feature flag
>> which removes bounds checks to the *safe* subset of Rust (
ed to the point where it can answer these sort of concerns, and that
those who make requests to flip off Rust's various safety features in the
safe subset of the language be gently guided towards the unsafe set of the
language while keeping the safe semantics exactly how they ar
On Fri, Mar 28, 2014 at 6:55 PM, Daniel Micay wrote:
> You can already use unchecked indexing in any case where there's a
> performance issue so I don't really understand what the fuss is about.
>
Confirm. This entire thread seems like much ado about nothing
language, based on
handwavy premature optimization. Based on that, I must say I abjectly
reject your ideas. I suggest you better formalize them, measure, and
present a more concrete plan which is rooted in empirical measurement, not
"hey I don't know what the hell I'm talking a
would do.
I'm not sure what your QA process normally entails, but can it guarantee a
build that is free of errors with *zero margin for failure*?
Anything less is a step back from what Rust currently provides, IMO.
--
Tony Arcieri
___
Rust-dev maili
On Thu, Mar 27, 2014 at 10:25 AM, Vladimir Lushnikov <
vladi...@slate-project.org> wrote:
> We do really need a good parser generator for rust though...
>
Ragel has a Rust backend (not that I've used it)
--
Tony Arcieri
___
Rust-dev
On Sun, Mar 23, 2014 at 11:50 AM, Corey Richardson wrote:
> Yes.
Cool! Who needs goto then? ;)
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
le of emitting? Can it do
labeled break/continue to generate jump-driven FSMs the same way it does
with Java?
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
transformed to whatever
> language --once there is a transformer--.
You realize Rust is suitable for this stuff today (or at least "soon"),
right?
Do you have an argument against Rust more cogent than "Rust is hard, let's
go shopping?"
--
Tony Arcieri
_
nyway, this problem will be solved when the compiler and linker been
> build in Go, instead of C.
>
Go allows unsafely shared memory as part of the core language. Game over
man, game over
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@moz
On Tue, Mar 4, 2014 at 11:43 AM, John Mija wrote:
> So, why don't use a simple language but safe like Go?
Go isn't a systems programming language. Go is a low-level managed language
with a mandatory runtime and garbage collector.
--
n
On Wednesday, February 26, 2014, Tony Arcieri wrote:
> Rust is using SipHash for std::hash (I believe?). This is a great
> conservative choice that mitigates hashDoS.
>
> However, it'd be nice if there were a faster option which still prevented
> an attacker from colliding paramete
I'd suggest the "default" hash function be hashDoS proof (since
attacker-controlled data has the tendency to leak deep into programs),
however a specifically performance-oriented hash/map (which isn't
hashDoS/collision resistant) should be available for those who wan
pplication startup. In the wild
universal hashing is used for things like UMAC:
http://en.wikipedia.org/wiki/UMAC
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
thub's UI too:
https://www.kernel.org/pub/software/scm/git/docs/git-notes.html
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
On Tue, Feb 4, 2014 at 2:29 AM, Jordi Boggiano wrote:
> I just hope whoever starts working on a new spec announces it clearly
THIS
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
ions of a package
depending on the given constraints, and concrete examples of how it would
work.
> Maven doesn't support this
>
Uhh, yes it does?
http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-DependencyVer
or and/or minor versions of a
particular package
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
that dependency?
>
I would like a constraints-based system that is able to calculate the
latest API-compatible version of a given package based on rules less strict
than version = X.Y.Z
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev
ackage, that the package maintainers release a hotfix for all major
versions.
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
using this (still extremely handwavey)
algorithm from depending on rust-json 1.0, 1.1, 1.2, 1.3, 1.4, 2.0, 2.1,
and 2.2 simultaneously?
What if some of these are buggy, but the fixed versions aren't used due to
version pinning?
What if rust-json 1.0 has a security issue?
--
Tony Arcieri
___
This made RubyGems support of multiple versions of
packages not only useless, but annoying, and even more cruft (e.g. rvm
gemsets) was added to work around the impedance mismatch between the
package manager and the dependency resolver.
I hope Rust will not make the same mistake for lack of better p
ersion of a package
vs
2) Solvable by many versions of the same package
vs
3) Unsolvable
Can you link me something which explains how this particular problem is
resolved specifically?
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozill
On Fri, Jan 31, 2014 at 3:11 PM, Tony Arcieri wrote:
> Can you link me something which explains how this particular problem is
> resolved specifically?
>
Also I would really like to see an example of a problem that can be solved
by multiple versions of a package which systems like Mave
dency resolution?
Can anyone point to a real-world example of a dependency resolver which can
produce solutions which may-or-may-not contain multiple versions of the
same library?
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
problem where
Maven/Bundler/apt-get/yum could not arrive on a solution that a system
which supports the installation of multiple simultaneous versions could
solve
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
>
I am still confused about:
1) In what situations are you saying there would actually be a workable
multi-version solution that wouldn't exist in a system like Maven
2) How these solutions are calculated
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
allows you to constrain
the dependency to a particular *major* version without requiring pinning to
a *specific* version.
I would call anything that requires pinning to a specific version an
antipattern. Among other things, pinning to specific versions precludes
software updates which may b
" school of thought
sounds nice in theory, but with nearly a decade of battle scars from
working with a system like that (RubyGems), my experience tells me it's a
terrible, terrible idea in practice...
--
Tony Arcieri
___
Rust-dev mailing list
R
up in
> practice"...
>
#trolololol
(Sorry, that was a typo, I meant to say "this doesn't come up as often as
you allege in practice")
Yes, I too have been dealing with dependency resolution problems for the
past 20 years... but I have also dealt with p
It's a bit silly, but certainly not
irresolvable.
I also don't think this comes up in practice as you allege. Perhaps it's
more frequent in systems that don't have a dependency resolver...
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
ltaneous versions of a library superior to
toposorting the dependencies and coming up with a combination of versions
that works for all of the project's dependencies?
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
d to an
explosion of incidental complexity in the form of things like gemsets.
In the presence of a dependency resolver this feature is not only useless
but annoying.
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.
kages are" concepts decoupled, as well as a clear strategy for how to
handle versioning.
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
like a valid use case that is probably best addressed by
cloning streams rather than splitting them.
Cloning streams would allow both that use case and reduce the total number
of types, as splitting would result in a "type explosion" (e.g. TcpStream,
On Wed, Jan 29, 2014 at 1:12 PM, Daniel Micay wrote:
> I don't think it's possible to make a nice NSS binding because it
> depends on thread-local initialization.
:(
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@m
is the time to
scrap it and build a better one. Otherwise we'll be stuck with it forever.
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
;d be nice if there were an official "blessed" crypto package
(using TBD packaging system). I think this library should/needs to be
shipped with said TDB packaging system.
Perhaps Mozilla could loop in its NSS people on rust-nss?
--
Tony Arcieri
y you.
I would definitely not be a fan of a non-battle hardened crypto library
being in core Rust.
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
h lock-free operations to eliminate
unnecessary system calls has been used somewhat successfully in the Netty
I/O library for the JVM.
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
the same time.
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
ily performance-oriented one), the actor model (which is
many-to-one by design) is probably going to be the most useful to people.
Just my 2c. I see actors as a generalized, higher-level pattern that can be
built atop CSP, and one I would love to see support for (in the form of an
Erlang/OTP-alike f
My vote, FWIW
let (sender, receiver) = Chan::open();
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
if you have anything valuable to add that
> isn't bikeshedding! :)
>
As probably the primary instigator of this change, I'd just like to say
you've done a great job resolving my original complaints, thanks ;)
--
Tony Arcieri
___
R
On Thu, Jan 23, 2014 at 7:29 PM, Benjamin Striegel
wrote:
> And Chan::open() doesn't map to anything that's as intuitive.
>
Like File::open? :P
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
idea...
Channel::open()
https://lh3.ggpht.com/-WpuYGqCEHDg/UBznzaqReKI/B_0/0Vc8_mnnhqw/s1600/mind-blown.gif
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
diagnostics around for new statically-typed languages. But there is always
> room for improvement of course.
>
#11718 is a great example. If there are other specific things that
particularly bug me, I'll let you know ;)
--
Tony Arcieri
__
I see there's some work underway of this nature ;)
https://github.com/mozilla/rust/pull/11718
On Tue, Jan 21, 2014 at 9:48 PM, Tony Arcieri wrote:
> I think the biggest thing I've struggled with learning Rust is what I will
> call, for lack of a better phrase, "shit rustc
lk on InfoQ:
http://www.infoq.com/presentations/php-history
Or the slides:
https://github.com/strangeloop/StrangeLoop2013/blob/master/slides/sessions/Adams-TakingPHPSeriously.pdf
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
t; succeeded, the channel is full, or the channel is closed (the last two
> cases returning the message). In the special case where the channel bound
> is 0, we don't use a ringbuffer and just do a rendezvousing send and
> recieve. The default bound is 0.
Nice! This so
gt; Rust-dev@mozilla.org
> > https://mail.mozilla.org/listinfo/rust-dev
> >
>
>
>
> --
> Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt
> "If you are silent about your pain, they'll kill you and say you enjoyed
> it."
> -- Zo
, I'd highly encourage taking a look at The
Update Framework as a way to build *secure* software update systems:
https://github.com/theupdateframework/tuf
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
ut if there are bigger fish to fry here, then cool ;)
Isn't this just a dtor thing?
>
YES!
This sounds like a general IO optimisation, which virtually any block-based
> io use-case could benefit from.
>
Yup! Can we solve it? ;)
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
1 - 100 of 117 matches
Mail list logo
