Steven D'Aprano wrote:
... as it goes, De Carte leads his horse into town;-)and having
>> hitched it to the rail outside the local saloon and sauntering up to
>> the bar, the tender asks, "Would you be hav'in an ale sir?"
>>
>> ... De Carte replies, "I think not..." ... and then disap
On Fri, 20 May 2011 15:45:03 -0700, geremy condra wrote:
> On Fri, May 20, 2011 at 1:24 PM, harrismh777
> wrote:
>> ... as it goes, De Carte leads his horse into town ;-) and having
>> hitched it to the rail outside the local saloon and sauntering up to
>> the bar, the tender asks, "Would yo
On Fri, May 20, 2011 at 1:24 PM, harrismh777 wrote:
> Steven D'Aprano wrote:
>>
>> Nonsense. How do you (generic "you", not any specific person) know that
>> you are not an idiot?
>
> lol Sum, ergo Idiot cogitat.
>
>
> Reminds me of a philosophical story I heard one time from my religion
> pro
Steven D'Aprano wrote:
Nonsense. How do you (generic "you", not any specific person) know that
you are not an idiot?
lol Sum, ergo Idiot cogitat.
Reminds me of a philosophical story I heard one time from my religion
professor...
... as it goes, De Carte leads his horse into town ;-)
On Fri, 20 May 2011 07:10:45 +, Steven D'Aprano wrote:
> How confident are we that the verification software tests every possible
> vulnerability,
Formal verification is based upon mathematical proof, not empirical
results.
As Dijkstra said: "Program testing can be used to show the presence
On Fri, May 20, 2011 at 12:10 AM, Steven D'Aprano
wrote:
> On Thu, 19 May 2011 17:56:12 -0700, geremy condra wrote:
>
>> TL;DR version: large systems have indeed been verified for their
>> security properties.
>
> How confident are we that the verification software is sufficiently bug-
> free that
On Mon, May 16, 2011 at 9:06 AM, Littlefield, Tyler wrote:
> I'm putting lots of work into this. I would rather not have some script
> kiddy dig through it, yank out chunks and do whatever he wants. I just want
> to distribute the program as-is, not distribute it and leave it open to
> being hacke
On 20 May 2011 07:04:27 GMT, Steven D'Aprano
wrote:
: On Fri, 20 May 2011 05:48:50 +0100, Hans Georg Schaathun wrote:
:
: > Either way, the assumption that your system will not be handled by
: > idiots is only reasonable if you yourself is the only user.
:
: Nonsense. How do you (generic "yo
On Thu, 19 May 2011 17:56:12 -0700, geremy condra wrote:
> TL;DR version: large systems have indeed been verified for their
> security properties.
How confident are we that the verification software is sufficiently bug-
free that we should trust their results?
How confident are we that the verif
On Fri, 20 May 2011 05:48:50 +0100, Hans Georg Schaathun wrote:
> Either way, the assumption that your system will not be handled by
> idiots is only reasonable if you yourself is the only user.
Nonsense. How do you (generic "you", not any specific person) know that
you are not an idiot?
If you
geremy condra wrote:
Anonymous, "Maximum Linux Security: A Hacker's Guide to Protecting
> Your Linux Server and Workstation," Indianapolis:
> Sams Publishing, 2000.
This is a good volume, but very dated. I'd probably pass on it.
Actually, although dated, its still a very go
On Thu, 19 May 2011 17:56:12 -0700, geremy condra
wrote:
: TL;DR version: large systems have indeed been verified for their
: security properties.
: (...)
: Yup. Nothing is safe from idiots.
The difficult part is mapping those properties to actual requirements
and threat models. Formal meth
On Fri, May 20, 2011 at 12:30 PM, geremy condra wrote:
>> On Fri, May 20, 2011 at 10:56 AM, geremy condra wrote:
>>> Yup. Nothing is safe from idiots.
>
> I actually think I need to take this statement back. The more I think
> about it, the less convinced I am that it's correct- I can at least
>
On Thu, May 19, 2011 at 6:33 PM, Chris Angelico wrote:
> On Fri, May 20, 2011 at 10:56 AM, geremy condra wrote:
>>> Speaking of reasonable assumptions, one necessary assumption which is
>>> particularly dodgy is that whoever deploys and configures it
>>> understands all the assumptions and do not
On Fri, May 20, 2011 at 10:56 AM, geremy condra wrote:
>> Speaking of reasonable assumptions, one necessary assumption which is
>> particularly dodgy is that whoever deploys and configures it
>> understands all the assumptions and do not break them through ignorance.
>
> Yup. Nothing is safe from
On Thu, May 19, 2011 at 11:23 AM, Hans Georg Schaathun
wrote:
> On Thu, 19 May 2011 10:23:47 -0700, geremy condra
> wrote:
> : Let me get this straight: your argument is that operating *systems*
> : aren't systems?
>
> You referred to the kernel and not the system. The complexities of
> the
On Thu, 19 May 2011 10:23:47 -0700, geremy condra
wrote:
: Let me get this straight: your argument is that operating *systems*
: aren't systems?
You referred to the kernel and not the system. The complexities of
the two are hardly comparable.
There probably are different uses of system; in
On Wed, May 18, 2011 at 7:54 PM, harrismh777 wrote:
> Littlefield, Tyler wrote:
> Four resources that you will what to look into, in no particular order:
>
> Erickson, Jon, "Hacking: The Art of Exploitation," 2nd ed,
> San Francisco: No Starch Press, 2008.
This would be a very good choi
On Wed, May 18, 2011 at 10:21 PM, Hans Georg Schaathun
wrote:
> On Wed, 18 May 2011 14:34:46 -0700, geremy condra
> wrote:
> : Systems can be designed that are absolutely secure under reasonable
> : assumptions. The fact that it has assumptions does not make your
> : statement true.
> : (...
On 19 May 2011 08:47:28 GMT, Steven D'Aprano
wrote:
: The real barrier to cracking Oyster cards is not that the source code is
: unavailable, but that the intersection of the set of those who know how
: to break encryption, and the set of those who want to break Oyster cards,
: is relative
On Thu, 19 May 2011 06:21:08 +0100, Hans Georg Schaathun wrote:
> : Are you talking about the Mayfair classical cipher here?
>
> I am talking about the system used in public transport cards like Oyster
> and Octopus. I am not sure how classical it is, or whether
> mayfair/mayfare referred to th
On Wed, 18 May 2011 14:34:46 -0700, geremy condra
wrote:
: Systems can be designed that are absolutely secure under reasonable
: assumptions. The fact that it has assumptions does not make your
: statement true.
: (...)
: I can't tell if you're trying to play word games with the distinction
Littlefield, Tyler wrote:
I know about rate limiting and dos attacks, as well as some others, but
I think there's a lot more that I don't know--can someone kind of aim me
in the right direction for some of this? I want to be able to take
techniques, break my server and then fix it so that can't b
On Wed, May 18, 2011 at 11:26 AM, Littlefield, Tyler
wrote:
>>might be secure as long as attackers cannot, say:
> You forgot UFOs.
> Anyway, again, thanks to everyone for the advice, this is good reading.
> Incidentally, I don't know to much about security. I know about rate
> limiting and dos att
On Wed, May 18, 2011 at 12:56 PM, Hans Georg Schaathun
wrote:
> On Wed, 18 May 2011 12:07:49 -0700, geremy condra
> wrote:
> : I was playing around with an HSM the other day that had originally
> : targeted FIPS 140-3 level 5, complete with formal verification models
> : and active side-chan
On Wed, 18 May 2011 12:07:49 -0700, geremy condra
wrote:
: I was playing around with an HSM the other day that had originally
: targeted FIPS 140-3 level 5, complete with formal verification models
: and active side-channel countermeasures. I'm quite confident that it
: was secure in nearly
On Wed, May 18, 2011 at 10:33 AM, Hans Georg Schaathun
wrote:
> On Wed, 18 May 2011 09:54:30 -0700, geremy condra
> wrote:
> : On Wed, May 18, 2011 at 12:36 AM, Hans Georg Schaathun
> wrote:
> : > But then, nothing is secure in any absolute sense.
> :
> : If you're talking security and not
On Thu, May 19, 2011 at 4:26 AM, Littlefield, Tyler wrote:
>>might be secure as long as attackers cannot, say:
> You forgot UFOs.
> Anyway, again, thanks to everyone for the advice, this is good reading.
> Incidentally, I don't know to much about security. I know about rate
> limiting and dos atta
On Thu, May 19, 2011 at 4:31 AM, Dotan Cohen wrote:
> The python code should not be concerned with DDoS, that is what
> iptables is for. Remember, never do in code what Linux will do for
> you.
In general, yes. Denial of service is a fairly broad term, though, and
if there's a computationally-exp
On Wed, May 18, 2011 at 20:24, Chris Angelico wrote:
> Denial of service attacks are the hardest to truly defend against, and
> if your level of business is low enough, you can probably ignore them
> in your code, and deal with them by human ("Hmm, we seem to be getting
> ridiculous amounts of tra
On Wed, May 18, 2011 at 20:24, Chris Angelico wrote:
> But you CAN make a system 100% secure against network-based
> attacks.
>
Only by unplugging the network cable. This is called an air gap, and
is common in military installations. Anything with a cable plugged in
is hackable.
--
Dotan Cohen
>might be secure as long as attackers cannot, say:
You forgot UFOs.
Anyway, again, thanks to everyone for the advice, this is good reading.
Incidentally, I don't know to much about security. I know about rate
limiting and dos attacks, as well as some others, but I think there's a
lot more that
On Thu, May 19, 2011 at 3:40 AM, geremy condra wrote:
> Just a note: you can do many cool things to prevent the last from
> working, assuming you're talking about RSA fault injection attacks.
Sure. Each of those caveats can be modified in various ways; keeping
checksums of everything in memory, e
On Thu, May 19, 2011 at 3:31 AM, John Bokma wrote:
>> Agreed. Things can be secure if you accept caveats. A good server
>> might be secure as long as attackers cannot, say:
>> * Get physical access to the server, remove the hard disk, and tamper with it
>> * Hold a gun to the developer and say "Lo
On Wed, May 18, 2011 at 10:24 AM, Chris Angelico wrote:
> On Thu, May 19, 2011 at 2:54 AM, geremy condra wrote:
>> On Wed, May 18, 2011 at 12:36 AM, Hans Georg Schaathun
>> wrote:
>>> But then, nothing is secure in any absolute sense.
>>
>> If you're talking security and not philosophy, there i
Chris Angelico writes:
> On Thu, May 19, 2011 at 2:54 AM, geremy condra wrote:
>> On Wed, May 18, 2011 at 12:36 AM, Hans Georg Schaathun
>> wrote:
>>> But then, nothing is secure in any absolute sense.
>>
>> If you're talking security and not philosophy, there is such a thing
>> as a secure sy
On Wed, 18 May 2011 09:54:30 -0700, geremy condra
wrote:
: On Wed, May 18, 2011 at 12:36 AM, Hans Georg Schaathun
wrote:
: > But then, nothing is secure in any absolute sense.
:
: If you're talking security and not philosophy, there is such a thing
: as a secure system. As a developer you
On Thu, May 19, 2011 at 2:54 AM, geremy condra wrote:
> On Wed, May 18, 2011 at 12:36 AM, Hans Georg Schaathun
> wrote:
>> But then, nothing is secure in any absolute sense.
>
> If you're talking security and not philosophy, there is such a thing
> as a secure system. As a developer you should a
On Wed, May 18, 2011 at 12:36 AM, Hans Georg Schaathun
wrote:
> On Mon, 16 May 2011 23:42:40 +0100, Rhodri James
> wrote:
> : ...which is, of course, not exactly secure either. A sufficiently
> : determined hacker won't have much trouble disassembling a shared library
> : even if you do str
On Wed, May 18, 2011 at 10:36, Hans Georg Schaathun wrote:
> But then, nothing is secure in any absolute sense. The best you can
> do with all your security efforts is to manage risk. Since obfuscation
> increases the cost of mounting an attack, it also reduces risk,
> and thereby provides some
On Mon, 16 May 2011 23:42:40 +0100, Rhodri James
wrote:
: ...which is, of course, not exactly secure either. A sufficiently
: determined hacker won't have much trouble disassembling a shared library
: even if you do strip out all the debug information. By chance I'm having
: to do so
On Tue, 17 May 2011 16:39:48 +1000
Chris Angelico wrote:
> You have a point there. Although I can't guarantee that all my code is
> particularly *good*, certainly not what I'd want to hold up for a
> novice to learn from - partly because it dates back anywhere up to two
> decades, and partly becau
On Tue, May 17, 2011 at 4:16 PM, Dotan Cohen wrote:
> Actually, Chris, those applications are probably no less valuable to
> be open source than Linux or Firefox. The reason is that when one goes
> to learn a new language it is valuable to look at existing real world
> code. However, the code avai
On Mon, May 16, 2011 at 07:40, Chris Angelico wrote:
> And I'm sure Steven will agree with me that this is not in any way a
> bad thing. I've written hundreds of such programs myself (possibly
> thousands), and they have all served their purposes. On a slightly
> larger scale, there are even more
"Littlefield, Tyler" wrote:
> Anyway, thanks to everyone else who answered this thread. I've not done
> much like this besides muds, and all the logic is on the server there, I
> think I will build the client in python, open source it for people to
> fix/add to if they want and make sure to keep t
"Littlefield, Tyler" writes:
> Anyway, thanks to everyone else who answered this thread. I've not
> done much like this besides muds, and all the logic is on the server
> there, I think I will build the client in python, open source it for
> people to fix/add to if they want and make sure to keep
Grant Edwards writes:
> On 2011-05-16, Ben Finney wrote:
> > "Littlefield, Tyler" writes:
> >
> >> I'm putting lots of work into this. I would rather not have some
> >> script kiddy dig through it, yank out chunks and do whatever he
> >> wants. I just want to distribute the program as-is, not d
"Littlefield, Tyler" writes:
> I wanted to make the client in python, and the server possibly, though
> I'm not really sure on that. I was not worried about the code for the
> server being stolen, as much as I was worried about people tinkering
> with the client code for added advantages.
Thank
On Mon, 16 May 2011 03:21:00 +0100, Daniel Kluev
wrote:
On Mon, May 16, 2011 at 1:04 PM, Littlefield, Tyler
wrote:
Hello all:
Finally, is there a good way to accomplish this? I know that I can make
.pyc
files, but those can be disassembled very very easily with the
disassembler
and shi
Steven D'Aprano wrote:
To put it in a
nutshell, you can't trust*anything*. See the classic paper by Ken
Thompson, "Reflections on Trusting Trust":
This is true, but there's another way to put it pro-active---
... expect the client to be untrustworthy.
In other words, write the server code
On 05/15/2011 10:29 PM, Ben Finney wrote:
What is it you think you would gain by obfuscating the code,
and why is that worthwhile? What evidence do you have that
code obfuscation would achieve that?
Based on past experience at several employers', the preeminent
reason for obfuscating is to mak
On Mon, May 16, 2011 at 12:17 AM, Littlefield, Tyler
wrote:
>>Write your "game" for the "web".
>>Write is as a SaaS (Software as a Service) - even if it's free and open
>> source.
> I understood you loud and clear. And that makes a lot of assumptions on my
> game and the design. I don't really car
>Funny you should mention this "now"
I don't go around parading the info, until I have to.
>Yes I agree Flash is not very accessible (never has been).
>Web Standards web apps and such however are quite
>accessible!
If I was making a browser-based game, yes. As I'm not though...
Anyway, thanks to
On 2011-05-16, Ben Finney wrote:
> "Littlefield, Tyler" writes:
>
>> I'm putting lots of work into this. I would rather not have some
>> script kiddy dig through it, yank out chunks and do whatever he wants.
>> I just want to distribute the program as-is, not distribute it and
>> leave it open to
On Sun, 15 May 2011 23:41:23 -0600, Littlefield, Tyler wrote:
> Here's kind of what I want to prevent. I want to write a multi-player
> online game; everyone will essentually end up connecting to my server to
> play the game. I don't really like the idea of security through
> obscurity, but I w
Littlefield, Tyler wrote:
Hello:
Thanks all for your information and ideas. I like the idea of open
source; I have a fairly large (or large, by my standards anyway)
project that I am working on that is open source.
Here's kind of what I want to prevent. I want to write a multi-player
online
On Mon, May 16, 2011 at 6:49 PM, Steven D'Aprano
wrote:
> If your answer is "No cheating is acceptable", then you have to do all
> the computation on the server, nothing on the client, and to hell with
> performance. All your client does is the user interface part.
>
> If the answer is, "Its a MUD
On Sun, 15 May 2011 23:41:23 -0600, Littlefield, Tyler wrote:
> Here's kind of what I want to prevent. I want to write a multi-player
> online game; everyone will essentually end up connecting to my server to
> play the game. I don't really like the idea of security through
> obscurity, but I want
On Sun, May 15, 2011 at 10:41 PM, Littlefield, Tyler
wrote:
> Hello:
> Thanks all for your information and ideas. I like the idea of open source; I
> have a fairly large (or large, by my standards anyway) project that I am
> working on that is open source.
>
> Here's kind of what I want to prevent
On Mon, May 16, 2011 at 4:16 PM, Littlefield, Tyler wrote:
> I understood you loud and clear. And that makes a lot of assumptions on my
> game and the design. I don't really care to host this over the web. I want a
> centralized server that would perform the logic, where I can offload the
> playin
Hello:
I wanted to make the client in python, and the server possibly, though
I'm not really sure on that. I was not worried about the code for the
server being stolen, as much as I was worried about people tinkering
with the client code for added advantages. Most of the logic can be
handled b
>Write your "game" for the "web".
>Write is as a SaaS (Software as a Service) - even if it's free and
open source.
I understood you loud and clear. And that makes a lot of assumptions on
my game and the design. I don't really care to host this over the web. I
want a
centralized server that woul
On Mon, May 16, 2011 at 3:41 PM, Littlefield, Tyler wrote:
> Here's kind of what I want to prevent. I want to write a multi-player online
> game; everyone will essentually end up connecting to my server to play the
> game. I don't really like the idea of security through obscurity, but I
> wanted
On Mon, May 16, 2011 at 3:41 PM, Littlefield, Tyler wrote:
> Here's kind of what I want to prevent. I want to write a multi-player online
> game; everyone will essentually end up connecting to my server to play the
> game. I don't really like the idea of security through obscurity, but I
> wanted
Hello:
Thanks all for your information and ideas. I like the idea of open
source; I have a fairly large (or large, by my standards anyway) project
that I am working on that is open source.
Here's kind of what I want to prevent. I want to write a multi-player
online game; everyone will essentu
On Mon, May 16, 2011 at 2:03 PM, Steven D'Aprano
wrote:
> The best way to do that is to labour in obscurity, where nobody either
> knows or cares about your application. There are hundreds of thousands,
> possibly millions, of such applications, with a user base of one: the
> creator.
And I'm sur
"Littlefield, Tyler" writes:
> I'm putting lots of work into this. I would rather not have some
> script kiddy dig through it, yank out chunks and do whatever he wants.
> I just want to distribute the program as-is, not distribute it and
> leave it open to being hacked.
How do these arguments ap
On Sun, 15 May 2011 21:36:53 -0600, Littlefield, Tyler wrote:
> I'm putting lots of work into this. I would rather not have some script
> kiddy dig through it, yank out chunks and do whatever he wants.
The best way to do that is to labour in obscurity, where nobody either
knows or cares about
Littlefield, Tyler wrote:
I'm putting lots of work into this. I would rather not have some script
kiddy dig through it, yank out chunks and do whatever he wants. I just
want to distribute the program as-is, not distribute it and leave it
open to being hacked.
Protection via obfuscation is inval
I'm putting lots of work into this. I would rather not have some script
kiddy dig through it, yank out chunks and do whatever he wants. I just
want to distribute the program as-is, not distribute it and leave it
open to being hacked.
On 5/15/2011 9:29 PM, Ben Finney wrote:
"Littlefield, Tyler"
"Littlefield, Tyler" writes:
> I have been considering writing a couple of programs in Python, but I
> don't want to distribute the code along with them.
This topic has been raised many times before, and there is a response
which is now common but may sound harsh:
What is it you think you would
On Mon, May 16, 2011 at 12:21 PM, Daniel Kluev wrote:
> No, there is no way to prevent users from getting access to raw python
> sources. By its nature and design, python is not meant to be used this
> way, and even obfuscation would not harm readability much.
> However, you can write all parts yo
On Mon, May 16, 2011 at 1:04 PM, Littlefield, Tyler wrote:
> Hello all:
> Finally, is there a good way to accomplish this? I know that I can make .pyc
> files, but those can be disassembled very very easily with the disassembler
> and shipping these still means that the person needs the modules th
Hello all:
I have been considering writing a couple of programs in Python, but I
don't want to distribute the code along with them. So I'm curious of a
couple things.
First, does there exist a cross-platform library for playing audio
files, whose license I would not be violating if I do this?
74 matches
Mail list logo
