AltME groups: search
Help · search scripts · search articles · search mailing listresults summary
world | hits |
r4wp | 27 |
r3wp | 811 |
total: | 838 |
results window for this page: [start: 1 end: 100]
world-name: r4wp
Group: #Red ... Red language group [web-public] | ||
Kaj: 4-Jun-2012 | Red is actually quite suitable for CGI, because the compiled executables are absolutely tiny, like they were in languages such as C when CGI was introduced. This means the performance will be quite good, not like the performance hit CGI suffers with heavy modern programming environments such as REBOL where the whole virtual machine needs to be started for every request. At the same time, you still have the advantages that made CGI popular: simplicity, robustness and security | |
Pekr: 23-Aug-2012 | It is probably not related, but you might try with secure none, but I does not seem to be problem of REBOL's security or licence missing ... | |
DocKimbel: 23-Aug-2012 | The only cause I can think of is because the DLL produced by Red/System are not (yet) relocatable, they can be conflicting with other loaded DLLs (but shouldn't happen with a fresh REBOL session), or are triggering something in anti-virus or Windows security sub-systems. | |
Kaj: 22-Sep-2012 | Henrik, yes, Graham's link says that all the information is available. But then you're looking at complete reimplementations of a whole software suit that's extremely security critical | |
BrianH: 29-Oct-2012 | The new Windows Defenfer in Win8 is pretty much a relabeled Microsoft Security Essentials with a few more features. Haven't had a problem with MSE yet that wasn't resolvable. | |
DocKimbel: 30-Oct-2012 | Second thing I do: install Microsoft Security Essential (it's free) and forget about all common antivirus issues (slowness, instability, intrusive ads, false positives, ...). | |
BrianH: 20-Nov-2012 | Hopefully less buggy too. The rebcode dialect caused a lot of crashes and security holes, which is why it was removed. The new mechanism doesn't have that problem. | |
BrianH: 20-Nov-2012 | The advantage to rebcode isn't that it's fast, it's that its semantic model is similar to assembler. That makes it useful for a lot of interesting problems. Also, there might be times when you don't want to allow Red/System to be inlined - it's basically the same as unsafe code in C#, with the same security characteristics. | |
BrianH: 20-Nov-2012 | In Red, there might be an advantage to making a compiled rebcode equivalent (but without the stability and security bugs). Unlike REBOL (ignoring the debate), rebcode is inherently compilable. It wasn't designed to be interpreted the way REBOL was. It just had a fast interpreter implementation, which has been adapted to other dialects in R3. | |
BrianH: 23-Nov-2012 | Almost. It doesn't "replace" the word in all contexts, it registers another spelling for the word in the place where word symbols are stored, then when you refer to the word with either spelling it will point to the *same* word. However, if you write code like this: alias 'print 'stampa then that code, just by being loaded, creates two words in the user context with those two spellings. So when the ALIAS function links the two spellings then there is a conflict in the user context, where "stampa" refers to both the word 'stampa and is an alias for the word 'print and at runtime you can't really tell which word you mean. If the system resolves this conflict by resolving to the alias then you have overriden the original word, which makes ALIAS a security exploit. If it resolves to the original word then ALIAS simply doesn't work. Either way, the function needs to go away ASAP. | |
BrianH: 23-Nov-2012 | Right. As opposed to ALIAS, which can bring your system to a crashing halt, if you're lucky; if you're not lucky it will fail silently and stay a security hole. | |
Kaj: 23-Nov-2012 | Programming is a security hole. If you want to allow people to do safe programming, you have to make it safe by disallowing many things. That would obviously include ALIAS | |
DocKimbel: 3-Jan-2013 | Kaj: I share your security concerns about an appserver, but I don't think that other words datatypes can really be more secure. As long as you can force the LOADing of arbitrary input strings (without even evaluating the code), you could use it to make the symbol table blow up the memory. | |
BrianH: 7-Mar-2013 | It seems useful for dialects, and dialects are one of the main purposes of block parsing, and supposedly of Rebol. Beyond that it doesn't seem to be useful. It doesn't hurt to have it in there. Security was one of my initial concerns when Gabriele first proposed it, but R3's greater control of binding can be enough to deal with that issue so it's about as harmless as any method of implementing a dialect that allows code execution. | |
DocKimbel: 22-May-2013 | Yep, that might close a security hole for your TryRed I guess. You can also now build true closed-source software using Red. ;-) | |
Kaj: 22-May-2013 | There's a fundamental complaint among Android developers that you can't protect your apps against cracking, unlike on iOS, where Objective C apps are compiled. Petr showed how easy it is to decompile Android Java apps. With Red and the Java bridge, you can reach the same security on Android as native iOS apps. This could be an important marketing feature for Red | |
Group: Announce ... Announcements only - use Ann-reply to chat [web-public] | ||
Robert: 24-Mar-2012 | Saphirion's Host-kit has been updated: -added PNG encoder -added Core extension module for generic additional commands -reworked compile/build process -fixed security flaw in Encap -fixed bug caused non-functional networking -improved console output handling logic -patched ENCODE to not crash on png -updated LOAD-GUI with currentspahirion link -recompiled r3.exe, r3core.exe, r3encap.exe and r3ogl.exe Update on the web-page will be available on the weekend. | |
Arnold: 2-Aug-2012 | I have put my example script for CGI forms with validation and refilling previously filled fields online on the rebol.org site. http://www.rebol.org/view-script.r?script=cgi-form-val-example.r Maybe somebody with more (CGI security) expertise can look at it and comment on safety issues please. | |
Group: Ann-Reply ... Reply to Announce group [web-public] | ||
GrahamC: 26-Mar-2013 | Just checked LinkedIn, he's working for some company called homeland security | |
Group: Rebol School ... REBOL School [web-public] | ||
NickD: 23-Sep-2012 | There has to be something Rebol is doing beyond a simple language api to get level of security purported by Carl. What kind of pipes does it use? | |
Kaj: 23-Sep-2012 | There's nothing much special in REBOL regarding security | |
NickD: 23-Sep-2012 | My misunderstanding then. I do not even know what 'pipes' are. I am posing the question on behalf of another. The question started based on the understanding from a conversation with Carl concerning the security benefits of AltMe and the once pending contract with the CIA. | |
Group: !REBOL3 ... General discussion about REBOL 3 [web-public] | ||
Maxim: 21-Jan-2013 | but I'll probably be using modules as the basic construct for slim R3, instead of objects... in my model, it might not really matter, I manage access/biding to/from modules actually altering and expanding the module when it is being loaded. the data being sent to slim isn't executed directly, the block is sent to a manager, which does some binding and security stuff first. | |
BrianH: 27-Jan-2013 | I can imagine that if you want to have a module somehow negitiate some passwords and don't want them to leak, or some other security issue, you might want to write the module to be isolated. Also, if Maxim wanted to port slim to R3, or someone wanted to port Qtask (I forgot what it's called now, sorry) or some other code written for Gabriele's PowerMezz modules to R3, they might want to use named, private isolated modules. | |
BrianH: 7-Feb-2013 | And, it does break through the APPLY security trick, which I might want to review some code about. I think that needs a ticket. >> apply does [return/redo :add] [1 1] 1 1 == 2 | |
BrianH: 10-Mar-2013 | Look here http://issue.cc/r3/1921before you do this. Make sure the security constraints mentioned there are taken into account. | |
AdrianS: 6-Jun-2013 | I'd like to hear more about the security implications it has vs existing ways of affecting interpreted behaviour by self-modifying code. |
world-name: r3wp
Group: Script Library ... REBOL.org: Script library and Mailing list archive [web-public] | ||
Sunanda: 13-Sep-2005 | The same bot came back yesterday, via an anonymous proxy. We are not alone -- this outfit is probing flaws in HTML forms on many (non-REBOL sites). It would seem a reasonable security test on many websites to not allow sign-ups or feedback messages (etc) from anonymous proxies. | |
Graham: 26-Apr-2006 | It was irrational. Just security. | |
Group: Linux ... [web-public] group for linux REBOL users | ||
François: 10-Jul-2005 | I found a critical bug: when rebol is configured to work as cgi engine with SELinux (Security Enhanced Linux), it generates a Segmentation Fault. I uses Fedora Core 3 with SELinux to secure the httpd daemon. For now, if you want to use rebol as a cgi engine, you must disable SELinux. See RAMBO Ticket #-376 | |
Gabriele: 10-Oct-2005 | older View used it for the security requesters. not sure if this is still the case with 1.3 or not. | |
Group: CGI ... web server issues [web-public] | ||
François: 10-Jul-2005 | I found a critical bug: when rebol is configured to work as cgi engine with SELinux (Security Enhanced Linux), it generates a Segmentation Fault. I uses Fedora Core 3 with SELinux to secure the httpd daemon. For now, if you want to use rebol as a cgi engine, you must disable SELinux. See RAMBO Ticket #-376 | |
Volker: 5-Dec-2005 | 1) should be secure. decode-cgi should put only strings in the data, nothing executable. (i use a lot "should" when it comes to security and i did not double-check). But why do you do that? simply mold decode-cgi should give the same. | |
Group: Web ... Everything web development related [web-public] | ||
Chris: 30-Jan-2005 | Re. JS -- Netscape 4 used a technology called JS Style Sheets -- it was a horrific mess. IE lets you evaluate JS within CSS -- it is a security risk, and of course does not work if JS is turned off. Think of CSS as like an image format -- you don't evaluate PNGs, you just display them. | |
Group: Cookbook ... For http://www.rebol.net/cookbook/requests.html [web-public] | ||
DideC: 7-Jul-2005 | I use 'construct for security reason, but it's most understandable with 'make : | |
Group: Rebol/Flash dialect ... content related to Rebol/Flash dialect [web-public] | ||
Oldes: 16-Mar-2006 | I've added an experiment with the Flash's security model http://box.lebeda.ws/~hmm/rswf/index.php?example=161 (there is added new tag so update your rswf dialect from the page) I'm not sure if it's working, but it should because it produces the same thing as this Macromedia's tool http://www.macromedia.com/support/flashplayer/downloads.html#lcu | |
Group: Tech News ... Interesting technology [web-public] | ||
Sunanda: 16-Feb-2006 | Well Henrik, a basic rule of security is that attacks only get stronger, never weaker. So just wait a while...... :-) | |
Group: Plugin-2 ... Browser Plugins [web-public] | ||
Henrik: 3-May-2006 | are there any security issues? infinite popups or anything left that might bring it out of control? | |
JoshM: 3-May-2006 | Seriously, I'd love a list of any security problems that you guys have encountered as you've used the plugin. | |
Graham: 3-May-2006 | I haven't seen any, but then I've not tried to break security .. | |
Graham: 3-May-2006 | If the chat client wipes your hard drive, consider it a security exploit! | |
Carl: 3-May-2006 | Problem: the security certificate for IE has expired (about 2 months ago). We will need to renew it. | |
Henrik: 3-May-2006 | I need the plugin for an application that could potentially be used for a few thousand users in an open enterprise environment, but signed scripts and security are essential there. | |
Henrik: 3-May-2006 | Carl, one thing I thought about is how do you convince a user that the security in the plugin going through the webbrowser is trustworthy when the SSL icon in the browser window is not on? they might think that nasty stuff could be going on in the background. I think there needs to be some kind of indication that the script currently running is really secure. | |
Gregg: 3-May-2006 | The file shouldn't be that much bigger--not like going from Base to CommandView--so I'd say include everything needed for commercial use. Of course, this opens up security questions too (e.g. lib access). | |
BrianH: 4-May-2006 | Is this group more for bug fixes to the new plugin, or is it a place to make suggestions and discuss security issues? | |
Graham: 4-May-2006 | security exploits .. private message josh. | |
BrianH: 4-May-2006 | Security Issues: - We should to be able to restrict with the secure native what files and dlls the plugin can access. - The default security of the RT-provided plugin (not encapped by a third-party) should prohibit any access to any local files or libraries at all, even in the same directory as the script, and prohibit access to third-party network addresses as well. Or at least ask. - There should be some way to access the site's cookies from the plugin, because there shouldn't be any other way to store local data on the client computer's hard drive. Anything short of that will be a security hole. - There should be no way to reduce the default security of the plugin through the use of plugin params. - Any attempt to reduce access should prompt the user for permission, in terms a non-technical user can understand. This means rewriting the security dialogs to be more user-friendly. - Any relaxation of these default security restrictions should require encapping the script. - A user (or their lawyer) should to be able to (perhaps through RT) track down the author of any encapped script. - An encapped script should count as a seperate plugin as far as the user is concerned, at least as far as permission-to-install is concerned. Basically, the default security of the plugin should not allow scripts to do anything you wouldn't want your worst enemy to do on your computer. People will try to use this plugin for advertisements, for webbugs, for spyware, for every nasty thing that you aren't evil enough to think of. Avoiding that kind of thing should be the focus of the default security settings. Anything less will make the plugin unsafe to install. | |
BrianH: 4-May-2006 | Yes, and design the security dialog so that longer URLs are able to be fully shown,either by wrapping or scrolling. | |
BrianH: 4-May-2006 | We don't want the default plugin to be able to put even a single byte outside of the browser's purview without prompting the user first. Users have enough security problems to deal with without wondering if their banner ads are putting files on their hard drive. As it is I know many users who use AdBlock as a security measure - they don't care whether they see ads, but many of those ads contain nasty code and spyware installers. | |
BrianH: 4-May-2006 | That is the default security restriction of existing browser VMs. | |
BrianH: 4-May-2006 | The places a browser puts persistent data, and manages that data, are cookies and the temporary file cache. There are already security restrictions and management tools for those places. That existing persistent storage should be sufficient for REBOL scripts loaded by the regular plugin. Any other storage should be on the server, with the same server access restrictions as JavaScript. Anything more should be restricted to trusted sites. | |
Henrik: 4-May-2006 | if there is a breach in bank security it's all over the news immediately | |
BrianH: 4-May-2006 | Anonymous scripts should be able to read through the browser cache, at least for files from their own site, but should assume that those files won't necessarily persist beyond the browsing session. You don't want to give them a sandbox that doesn't have its space limited by the browser's existing facilities, for security and privacy reasons. You definitely don't want anonymous scripts to store more than cookies on your systems. The guideline you should set for default behavior of anonymous scripts is to limit it to the activities that would be OK for deliberately malicious code to do. Assume that all anonymous code is out to get you until proven otherwise. This is a browser plugin you know - it will be used in banner ads. | |
Graham: 4-May-2006 | Security settings often prevent users from installing applications .. so a browser app makes it easier for admins to distribute an application. | |
BrianH: 4-May-2006 | As for things like do-browser, it would be nice if the copy of REBOL called by the plugin could be passed some callbacks to which it would delegate some basic functionality like requesting a local file, proxy settings, do-browser, etc. This would allow the plugin to better integrate with the browser's existing behavior and security infrastructure. | |
BrianH: 4-May-2006 | By the way Josh, the security discussion we were having last night wasn't noise. Without the security restrictions discussed above noone would be able to safely install this plugin and allow it to run scripts from any but the most trusted sites. This is important. | |
JoshM: 4-May-2006 | thanks for the feedback. i apologize if i conveyed the idea that security discussions are noise. What I mean is that I don't have the bandwidth to sift through pages of discussion and build the plugin at the same time. So, for my sake, we need some kind of itemized system where Carl and I can tackle the issues one-by-one. | |
JoshM: 4-May-2006 | regarding security: so we need a list. i.e. change #1: disable xyz. change #2: make xyz a prompt that looks like this. etc. | |
BrianH: 4-May-2006 | Well, I can summarise the security proposals as discussed here and post them to your private message area if you prefer. | |
BrianH: 4-May-2006 | Sure, if you want. I'll edit the security entry I already put there. | |
BrianH: 4-May-2006 | I think that major versions should be installable side-by-side, and minor versions autoreplace so that security fixes can propagate. | |
Anton: 4-May-2006 | A minor security "fix" can also break older code. | |
BrianH: 4-May-2006 | Security fixes should only break insecure code. Otherwise they are API modifications. | |
BrianH: 4-May-2006 | I like the API being able to wrap a one dll from each generation, and then update that dll for security fixes. | |
JoshM: 4-May-2006 | Interesting. OK, so we're leaning towards parallel side-by-side installs with automatic overwrite updates for security fixes? | |
BrianH: 4-May-2006 | I think a prompt is better, particulary for security updates. | |
BrianH: 4-May-2006 | Security updates are too important not to prompt for. | |
BrianH: 4-May-2006 | Anton, that won't work for webbugs. We want the security updates to be visible even when the applet isn't. | |
BrianH: 4-May-2006 | Especially when the applet isn't, since those kind of applets are more likely to be exploiting security bugs. | |
JoshM: 5-May-2006 | Here are the scenarios with resolutions in boolean logic as I see them right now: 1. web_site_required_version not found on users computer -- download required version 2. web_site_required_version = version_on_computer && security_min_version > version_on_computer -- popup, request download security update 3. web_site_required_version = version_on_computer && security_min_version <= version_on_computer && latest_version > version_on_computer -- not sure | |
BrianH: 5-May-2006 | A legitimate webbug wouldn't be worried about showing a security update. An illegitimate one would be directly interested in hiding one since it may be depending on the security hole for exploit code. | |
JoshM: 5-May-2006 | Yes, we're assuming that the web site has no control over the security check, nor the security_min_version (that would come from RT) | |
JoshM: 5-May-2006 | So, we have a few different scenarios (using the numbering from above): 1. In this case, the activex system in IE will force the download of the (digitally signed) CAB found in the htm, which will come from RT, and contain the Plugin version that works with this system. Nothing new is required, this is how it works now. 2. Here we need to enhance REBOL somehow to check for a security update, prompt the user, and download an updater EXE. This is where I think I will work next. | |
BrianH: 5-May-2006 | We could be conservative and not make unrequested non-security updates. | |
JoshM: 5-May-2006 | Volker, that is true. But the problem here is not COM interface/version compatibility. The problem here is: "Which REBOL binary to load?" Very simply put, if a web site relies upon plugin version 1.3.2, we must make sure that 1.3.2 -- or a later version backwards-compatible with 1.3.2 -- loads on their computer. At the same time, we need to deliver critical security updates and other non-breaking updates to users in a seamless manner. | |
Ingo: 5-May-2006 | Should we inform the user is a new update is avalaible? I think this should be configurable for compatible updates. I guess some people might become nervous, if the plugin connects to the rebol.com site on every invocation. Even it is only looking for updates, well, you'll never know ... On incompatible updates: The user should get a message along the lines: "You have installed the Rebol 1.3.4 plugin, this website needs the 3.0 plugin" of course only, if that is true. I would ask for "download and install" for user convenience. Ver< few people would want to download and check the binary before installing it. Maybe you _could_ add a checkbox to "only download". Well, I hate popups, but I hate not getting inmportant info even more ... so, I start downloadinf a webpage, while this page is loading, I open another tab, and work on this. Now I return to my first page later, and I find an embedded message "We're sorry, you first need to download the new plugin version" would make me go crazy :-) So I would like a popup in this case. Well, when there is a new security update, for maximum security, the plugin should stop to work until the user has answered, wether he wants to update, or go with the old plugin. | |
Anton: 6-May-2006 | I agree with Maxim. Most people out there in the world don't have any reason to trust Rebol or Rebol Technology. It might be just another spyware company for all they know. Why would they (initially) want to allow an automatic software corridor into their computer ? It's an issue of trust. First let them try it out, then when they like what they see, allow them to enable more automatic security updates if they want. | |
Anton: 6-May-2006 | So can we store a flag somewhere in the system? automatic-security-updates = true / false; | |
Pekr: 7-May-2006 | 3) Integration - the toughest part - first - old plug-in way of integration was not optimal. REBOL's code of 'get-net-info is outdated and broken. First thing is to get proxy info automatically, if possible, but still allow it to be settable. Most corporate users do use proxy, without it, plug-in in non-existant product for corporate environment imo. Why to allow manual settings? Well, dunno how many companies do use it, but our company does :-( ..... "use script for proxy configuration" - and the script is JS code, which browser can interpret, but not rebol itself, so we need ability to set it manually ... or - second point and probably the main point from the architecture pov - do we allow what rebol allows? Do we allow our own networking, or will we allow only to tunnel via browser? One one hand, we would get https, on the other hand, if we limit it, we are not talking about rebol anymore, but sligthly different rebol based product. As for me, I am not able to see all the security related concerns, so I let it to others here ... | |
BrianH: 7-May-2006 | Henrik, with my suggested default network restrictions, that kind of security problem just won't happen without bringing up a security requestor that the user must agree to first. | |
BrianH: 7-May-2006 | With Java, the applet is only allowed to communicate with the server that served up the applet. We could make that same restriction by default in the REBOL plugin with SECURE, and then relax the restrictions at runtime with SECURE again. Of course, that will cause the security requester to pop up and the user would then know what they should know and agree to anyways before such behavior is allowed at all. | |
ScottT: 7-May-2006 | how about a simple flag, like a checkforupdates="true" attribute or something. Every other operation, including the sort of actions that are necessary to install update is handled through normal security requestors. ... yeah, like Brian said :) | |
Henrik: 9-May-2006 | I'm not sure that such information is possible through the DOM (which is where it would come from). wouldn't that be a security hole? | |
Ryan: 9-May-2006 | As far as web stuff goes, my customers want the "real life" apps. Security needs range from completely disabled to something like java's, but being able to save files locally (save-as requestor). | |
Volker: 10-May-2006 | Networking: as far as the browser can do the same, i would use browsers io. Or is it that much slower than rebols handler? Advantages are: proxy, cache. Maybe there are some extensions people like, about adds or blacklist or whatever? if such things exists they would be shared too. Its security , and a computer which knows my "no"s looks smarter. | |
Pekr: 10-May-2006 | ... still we need imo ability to use networking/security model of browser, for those who need it (networking via browser). The question is with security - should plug-in allow default rebol security? That is the question .... | |
ScottT: 11-May-2006 | same here with excess security dialogs. windows 2000 | |
Henrik: 11-May-2006 | wouldn't that be a security hole? | |
JoshM: 11-May-2006 | Or take security/licensing......we could have the plugin DLL automatically download the correct version EXE (View/ViewPro/Command/etc.) based on the version the script requires (so the initial download could be quite small, with a "download as needed" architecture) | |
JoshM: 11-May-2006 | No.....not a security hole. Acrobat works that way. | |
JoshM: 15-May-2006 | I am working on a design doc for making the default security settings for the plugin more restrictive. | |
JoshM: 15-May-2006 | I know we talked about it a while ago, but those discussions are long gone from REBOL and from the web......I apologize, I should have archived them. Can you repost your thoughts on the default security model, in *concise* posts please? thank you! | |
Volker: 15-May-2006 | Extra Security, some thoughts: - 'secure for ips, eg: secure [net ask tcp://rebol.com allow] - don't share sandbox-folders between hosts. - if possible memory-restriction, hd, cpu? - clipboard-restriction somehow? - check for memory-access, specially disable struct! . IMO real hackers will figure out how to inject code by poke. - reblets can store executable code by naming the file *.exe. Does not run immediate, but script can open folder in explorer by browse, and one wrong click runs it. (or is windows smarter now? Maybe you could add an own extension always, and maybe store everything as 64#{} ? - Make sure untrusted reblets don't run invisible, can snoop clipboard, or at least users online-times. I guess creatives can find other uses. - Maybe some kind of log about starts/stops, with urls? To have a little chance of tracking. Some kind of global console. - Running out of thoughts for now. | |
Sunanda: 15-May-2006 | A couple of quick thoughts: [*] Don't allow reading/writing outside of a local sandbox......That includes not allowing access to URLs elsewhere on the web. permitting wider local access and permitting wider web access should be separate security settings [*] Disallow send by default | |
Pekr: 15-May-2006 | I would not limit rebol networking at all, I would add some security, yes, but not limitation ... | |
Allen: 15-May-2006 | Volker. Jaime. Clipboard access should probably raise a security request, like it does in (secured) browsers. Maybe it should also be part of 'secure ... | |
ScottT: 15-May-2006 | Looks like Volker covered the security issues I'd note. About Rebol as a COM server process--I would think that would be the way to go. Pretty sure that is how Acrobat runs, too. Basically, the first time you run into a PDF on the web Acrobat32 starts, and handles all instances. | |
Oldes: 16-May-2006 | I agree, that some security is needed, but just want to say, not to give everything away just because there may be one bad guy | |
Oldes: 16-May-2006 | First thing what should be done is better security request window |
1 / 838 | [1] | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |