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
On Tue, Aug 11, 2015 at 6:58 PM, Sean McArthur smcart...@mozilla.com
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 Ferris.
--
Tony Arcieri
users 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
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
if data
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@mozilla.org
they should be used for anything serious.
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
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
___
Rust-dev mailing list
Rust-dev@mozilla.org
https
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
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
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 basc...@gmail.com wrote:
I've been trying to keep an eye on what's been brewing
On Mon, Sep 29, 2014 at 10:50 PM, Daniel Micay danielmi...@gmail.com
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?
___
;)
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
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
.
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
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 feel need to be called out while they're fresh in people's
minds.
--
Tony Arcieri
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 Sun, Sep 21, 2014 at 1:34 AM, Daniel Micay danielmi...@gmail.com 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 before you use this
--
Tony Arcieri
it,
gotta ship 1.0 before anyone gets a pony? ;)
On Sun, Sep 21, 2014 at 1:41 AM, Tony Arcieri basc...@gmail.com 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 focus
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 by proof
--
Tony
?
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
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 --
From: Tony Arcieri basc...@gmail.com
Date
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
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 overflow
operators)
--
Tony Arcieri
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 provide, which is sad if that's the way
the cookie crumbles...
--
Tony Arcieri
O Mon, Jun 23, 2014 at 2:08 PM, Tony Arcieri basc...@gmail.com 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 ;)
--
Tony Arcieri
how it 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
.
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
On Mon, Jun 23, 2014 at 3:08 PM, Tony Arcieri basc...@gmail.com 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 default?
--
Tony Arcieri
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
future CPUs 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
://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 list
Rust-dev@mozilla.org
https://mail.mozilla.org
/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
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 proper (even if it's
just flags for MemoryMap)
--
Tony Arcieri
is ChaCha20.
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
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 stick to it.
--
Tony
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
___
Rust-dev mailing list
Rust-dev
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
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
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
___
Rust-dev mailing
Thompsonesque backdoors? ;)
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
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 about but think this thing is
slow
--
Tony
On Fri, Mar 28, 2014 at 6:55 PM, Daniel Micay danielmi...@gmail.com 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.
--
Tony Arcieri
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 are.
--
Tony Arcieri
' is 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 (i.e. outside
of unsafe blocks)
I think this sort
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 mailing list
Rust-dev
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 mailing list
Rust-dev
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
On Sun, Mar 23, 2014 at 11:50 AM, Corey Richardson co...@octayn.net wrote:
Yes.
Cool! Who needs goto then? ;)
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
On Tue, Mar 4, 2014 at 11:43 AM, John Mija jon...@proinbox.com 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.
--
Tony Arcieri
, 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@mozilla.org
https
be 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
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
.
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 want to opt
into it.
--
Tony Arcieri
on
On Wednesday, February 26, 2014, Tony Arcieri basc...@gmail.com 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 parameters, right
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 j.boggi...@seld.be 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
compatibility is hard, let's go shopping! 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
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 planning.
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https
)
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
___
Rust
, 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
of a
particular package
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
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-DependencyVersionRanges
--
Tony Arcieri
On Wed, Jan 29, 2014 at 1:12 PM, Daniel Micay danielmi...@gmail.com 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@mozilla.org
at the same time.
--
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
___
Rust-dev mailing list
Rust-dev
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
://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
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 basc...@gmail.com 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 says
of the best
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
___
Rust-dev
and say you enjoyed
it.
-- Zora Neale Hurston
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https
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 sounds awesome.
--
Tony Arcieri
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
, at least if all the crypto libraries
used it, because this type would take care of doing all of this sort of
thing for you automatically.
Most other languages completely punt on this problem. Can Rust do better?
Is this the sort of thing that belongs in the Rust standard library?
--
Tony Arcieri
!
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
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
to spot. I've run into cases where we didn't
spot problems until we deployed to production because the production
section of a configuration file was misindented.
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org
. Is it a bad idea? Offhand I
can't say: what would you replace it with?
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
of something else.
So if we're talking to a payment gateway, our automated tests should run
against the live payment gateway? Surely you see there are many cases where
this simply doesn't work.
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
indenting your code correctly anyway.
Anyway, that's my two cents. I am not a fan of whitespace sensitivity.
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
another YAML file that someone started
with 2-space tabs? Do you convert everything to 8? Use 8-space tabs just
for your stuff and leave the rest of the file with 2-space tabs?
I would venture to guess that 8-space YAML files are exceedingly uncommon.
I'd also say 8-space tabs are ugly.
--
Tony
-class primitives.
Crazy idea: push channels out of the standard library ala
libgreen/libnative, and provide a trait for channel-alikes. Come up with a
least common denominator protocol, and ensure all channel-alikes support it.
--
Tony Arcieri
___
Rust-dev
expressed for all runtime conditions.
This is an excellent point, thank you!
So here's a big question: if Rust tasks and channels were the underpinnings
of an operating system kernel, would unbounded channels be suitable or not?
--
Tony Arcieri
___
Rust-dev
. I've helped many people debug overloaded systems
that didn't have sufficient mechanisms for internal backpressure between
actors in Celluloid.
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
will generally have non-message events
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
this because I'm a REPL-lover and Rust's existing REPL is broken.
It's not meant to be a permanent REPL for Rust, but a stopgap solution for
those who want a REPL until Rust ships a working one.
Enjoy!
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev
Rust programs don't grow
until they consume system resources and OOM.
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
) that will confer maximum performance.
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
On Tue, Dec 3, 2013 at 11:28 PM, Isaac Dupree
m...@isaac.cedarswampstudios.org wrote:
I'm interested in having persistent data structures[1] in Rust.
Nice!
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org
profound effect, IMO.
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
90 matches
Mail list logo