We can check the function pointer passed to rb_define_global_function
like we do so in rb_define_method. It turns out that almost anybody
is misunderstanding the API.
The result should only be tainted if the path given to the method
was tainted.
The code to always taint the result was added in
a4934a42cb (svn revision 4892) in
2003 by matz. However, the change wasn't mentioned in the
commit message, and it may have been committed by accident.
Skip part of a readline test that uses Reline. Reline in general
would pass the test, but Reline's test mode doesn't raise a
SecurityError if passing a tainted prompt and $SAFE >= 1. This
was hidden earlier because File#path was always returning a
tainted string.
Fixes [Bug #14485]
The result should only be tainted if the path given to the method
was tainted.
The code to always taint the result was added in
a4934a42cb (svn revision 4892) in
2003 by matz. However, the change wasn't mentioned in the
commit message, and it may have been committed by accident.
Skip part of a readline test that uses Reline. Reline in general
would pass the test, but Reline's test mode doesn't raise a
SecurityError if passing a tainted prompt and $SAFE >= 1. This
was hidden earlier because File#path was always returning a
tainted string.
Fixes [Bug #14485]
CI shows it does work on Solaris 11, but does not work on Solaris
10. However, until I figure out a good way to differentiate
between Solaris 10 and 11, this should get CI passing on both.
This approach is simpler than the previous approach which tries to
emulate realpath(3). It also performs much better on both Linux and
OpenBSD on the included benchmarks.
By using realpath(3), we can better integrate with system security
features such as OpenBSD's unveil(2) system call.
This does not use realpath(3) on Windows even if it exists, as the
approach for checking for absolute paths does not work for drive
letters. This can be fixed without too much difficultly, though until
Windows defines realpath(3), there is no need to do so.
For File.realdirpath, where the last element of the path is not
required to exist, fallback to the previous approach, as realpath(3)
on most operating systems requires the whole path be valid (per POSIX),
and the operating systems where this isn't true either plan to conform
to POSIX or may change to conform to POSIX in the future.
glibc realpath(3) does not handle /path/to/file.rb/../other_file.rb
paths, returning ENOTDIR in that case. Fallback to the previous code
if realpath(3) returns ENOTDIR.
glibc doesn't like realpath(3) usage for paths like /dev/fd/5,
returning ENOENT even though the path may appear to exist in the
filesystem. If ENOENT is returned and the path exists, then fall
back to the default approach.
With the SDK of Xcode 10.2.1, `API_AVAILABLE` and so on macros are
not defined in <os/availability.h> when using a compiler other
than clang (which has `__has_feature` and `__has_attribute`), but
`__API_AVAILABLE` macro and so on are defined, which are also
defined in <Availability.h>.
I suspect this is a bug of the SDK.
This string can include elements that were not in either string
passed to File.realpath, even if one of the strings is an
absolute path, due to symlinks:
```ruby
Dir.mkdir('b') unless File.directory?('b')
File.write('b/a', '') unless File.file?('b/a')
File.symlink('b', 'c') unless File.symlink?('c')
path = File.realpath('c/a'.untaint, Dir.pwd.untaint)
path # "/home/testr/ruby/b/a"
path.tainted? # should be true, as 'b' comes from file system
```
[Bug #15803]
* file.c (rb_file_s_birthtime): export for pathname to check if
birthtime is supported.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67097 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
The return value of major() and minor() is unsigned int, not dev_t.
So, UINT2NUM() is a better choice than DEVT2NUM().
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65319 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* file.c (rb_file_setuid_p): rdoc for IO object support
(rb_file_sgid_p): ditto (rb_file_sticky_p): ditto
* NEWS: inform users of new feature
* test/file/test_file_exhaustive.rb (io_open): wrapper for bare IO
object (test_suid): test for bare IO support (test_sgid): ditto
(test_sticky): ditto
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65235 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
The former states explicitly that the argument must be a literal,
and can optimize away `strlen` on all compilers.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65059 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* file.c (realpath_rec): fallback to symlink path when it is
accessible but the link target is not actual entry on file
systems. [ruby-dev:50487] [Bug #14557]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@62607 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* file.c (rb_file_s_stat): File.stat does not accept an IO
object as trying conversion to path name string first. skip
conversion to IO and try stat(2) only.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@62606 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Needlessly exporting can reduce performance locally and increase
binary size.
Increasing the footprint of our C-API larger is also detrimental
to our development as it encourages tighter coupling with our
internals; making it harder for us to preserve compatibility.
If some parts of the core codebase needs access to globals,
internal.h should be used instead of anything in include/ruby/*.
"Urabe, Shyouhei" <shyouhei@ruby-lang.org> wrote:
> On Thu, Jan 18, 2018 at 7:33 PM, Eric Wong <normalperson@yhbt.net> wrote:
> > shyouhei@ruby-lang.org wrote:
> >> https://svn.ruby-lang.org/cgi-bin/viewvc.cgi?view=revision&revision=61908
> >>
> >> export rb_mFConst
> >
> > Why are we exporting all these and making the public C-API bigger?
> > If anything, we should make these static. Thanks.
>
> No concrete reason, except they have already been externed in 2.5.
> These variables had lacked declarations so far, which resulted in their
> visibility to be that of extern. The commit is just confirming the status quo.
>
> I'm not against to turn them into static.
This reverts changes from r61910, r61909, r61908, r61907, and r61906.
* transcode.c (rb_eUndefinedConversionError): make static
(rb_eInvalidByteSequenceError): ditto
(rb_eConverterNotFoundError): ditto
* process.c (rb_mProcGID, rb_mProcUid, rb_mProcID_Syscall): ditto
* file.c (rb_mFConst): ditto
* error.c (rb_mWarning, rb_cWarningBuffer): ditto
* enumerator.c (rb_cLazy): ditto
[Misc #14381]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@62029 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
POSIX only defines mode_t to be "an integer typea", and in fact
MacOS defines it to be uint16_t. We didn't have NUM2USHORT before
so it did not make sense but now that we have it. Why not check
apptopriately.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@61950 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Support nanosec file timestamp on Windows 8 or later.
Original patches are written by kubo (Kubo Takehiro).
Windows 7 and earlier also supports nanosec file timestamp, but it's too
accurate than system time. so, this feature is disabled on such versions.
[Feature #13726]
this change also includes [Misc #13702]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@61013 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
David Rodríguez
卜部昌平
Jeremy Evans
Yusuke Endoh
git
Nobuyoshi Nakada
glass
nobu
ko1
mame
aycabta
stomar
normal
shyouhei
kazu
usa