r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[Core] Discuss core issues

Gabriele
20-Sep-2009
[14774]
You need at least one password you don't store; otherwise, you can 
only try to keep your files out of anyone else hands.
Maxim
20-Sep-2009
[14775]
true
Gabriele
20-Sep-2009
[14776x2]
And, this is not a problem that *your* app has to solve. It is just 
wasted time for you. Either you make use of a password manager, or 
just use obfuscation.
I'd just use encloak with some random text. If you think it's easy 
enough to get a system specific key, you might do that, but I don't 
know if users will be happy to find out that their passwords don't 
work anymore when they upgrade their PC or move to another computer.
Maxim
20-Sep-2009
[14778x2]
its for a client app... so its not a big issue... its only so the 
software remembers the login for subsequent calls to the server... 
just like all the browsers & OS "do you want   xxxxxx   to remember 
this password"
I'll use real encryption (using command)
Gabriele
20-Sep-2009
[14780]
Right, and do you think that the browsers are secure, or use a secret 
algorithm for that? :)
Maxim
20-Sep-2009
[14781]
its a choice I make.  and I know every single piece of data on my 
computer is vulnerable.
Gabriele
20-Sep-2009
[14782x2]
using real encryption does not make any difference... but anyway.
that is what I'm saying... so why waste time with some complicated 
scheme to store the password?
Maxim
20-Sep-2009
[14784x2]
I mean Gabriele, no system in the world is ultimately secure.  The 
point is only to make it unfeasible.
cause its going to be requested from every user the first time they 
have to "re-login"  ;-)
Gabriele
20-Sep-2009
[14786x5]
I don't think my point is clear...
I'm saying that it's a waste of time to try to make it "more secure"
or "more unfeasible"
just use encloack and obfuscate it so that it does not jump to the 
eyes.
if someone *wants* to get your password they will get it. so why 
bother?
Maxim
20-Sep-2009
[14791x2]
to make the client happy (the one paying for the application  ;-)
I mean paying me to build it... not the end-user ... ;-)
Gabriele
20-Sep-2009
[14793]
is the client paying you to use a machine specific id and some secret 
encryption scheme?
Maxim
20-Sep-2009
[14794x3]
he'll want the stored password  toat least require effort and thus 
a real cracker to break the binary. 


this feature will be added later, if ever, it wont for initial public 
release specifically for the reasons you talk about and which I already 
had the same conclusions.
toat = to at
this discussion just re-inforces my POV wrt not including the password 
save feature for now.
Gabriele
21-Sep-2009
[14797]
what does you make presume that he'll want that? and, what does "real 
cracker" mean?
Graham
30-Sep-2009
[14798x2]
What's the quick way of getting the root directory ?

This seems tortuous 

rootdir: to-file rejoin [ "/" second parse/all what-dir "/" "/" ]
copy/part what-dir 3

is shorter
BrianH
30-Sep-2009
[14800]
On Windows: read %//
Graham
30-Sep-2009
[14801x2]
sorry ... I meant I want %/c/   ... and not read the directory
ie. want the path
BrianH
30-Sep-2009
[14803x2]
Then your second method is best, unless you are on a UNC path, then 
try this: copy/part find/tail next what-dir "/"
Sorry, this:
rootdir: copy/part rootdir: what-dir find/tail next rootdir "/"
Sunanda
30-Sep-2009
[14805]
Does this do it?
    clean-path %//
BrianH
30-Sep-2009
[14806x3]
It should. It does on R3. Let me try it on R2.
Yup. On R3 it's slower though, sincee clean-path is mezz.
On R3 the fastest way is this: head clear find/tail next what-dir 
"/"
Graham
30-Sep-2009
[14809x2]
http://rebol.wik.is/Cheyenne/Upload-file.rsp
don't think I'll need UNC path support :)
BrianH
30-Sep-2009
[14811]
I use it a lot :)
Graham
30-Sep-2009
[14812]
on a web server?
BrianH
30-Sep-2009
[14813]
Nope - remote file manipulation. UNC paths are for Windows shares, 
not web shares.
Henrik
4-Oct-2009
[14814]
Ratio is giving me good opportunities to sharpen my skills. While 
writing a post, I bumped into this:

http://www.rebol.org/view-script.r?script=substr.r

What do you think? :-)
Dockimbel
4-Oct-2009
[14815]
From the script header: Purpose: "Working around string series"...I 
think that this is shooting yourself in the foot.
Graham
8-Oct-2009
[14816]
Don't you think this is a little inconsistent?

>> a: ""
== ""
>> a/1
== none
>> last a
** Script Error: Out of range or past end
** Near: last a
>>
Dockimbel
8-Oct-2009
[14817]
IIRC, Carl explained (at least) once that this behaviour is different 
on purpose. Using path notation with an index value or PICK should 
return NONE while using the prefix notation FIRST, SECOND,...LAST 
should return an error. So you have the choice to either silently 
handle missing values in series or raise an error!.
BrianH
8-Oct-2009
[14818x2]
In R3 it is consistent.
>> a: ""
== ""
>> a/1
== none
>> last a
== none
Will
15-Oct-2009
[14820x2]
SYSTEM/SCHEMES/FTP/PASS is a none of value: none
  set-net ['abc]
  ? system/schemes/ftp/pass
SYSTEM/SCHEMES/FTP/PASS is a string of value: "abc"
the documentation says "The first value is your email address and 
it is used when sending email and connecting to FTP. This value is 
stored in the REBOL system object at: SYSTEM/USER/EMAIL".

I don't think it's a good idea that the ftp password will be set 
to the email address as well, "used when connecting to FTP" maybe 
it should set the user instead
Graham
16-Oct-2009
[14822]
that's the way it used to be done
Gabriele
16-Oct-2009
[14823]
the convention for anonymous FTP is to provide "anonymous" as the 
user and the email address as the password.