Skip to content

[R-pkg-devel] CRAN submissions down?

16 messages · Roy Mendelssohn - NOAA Federal, John C Nash, Hadley Wickham +5 more

Original
Dirk Eddelbuettel
#
On 9 January 2026 at 08:11, Hadley Wickham wrote:
| Is this just a me problem, or is https://xmpalantir.wu.ac.at/cransubmit/
| down for others too?
Folder                  Name                Time   Size        Age
    <char>                <char>              <POSc> <char> <difftime>
1: pretest     NNS_11.6.4.tar.gz 2026-01-09 15:26:00   1.9M 0.04 hours
2: pretest   ggsced_0.1.2.tar.gz 2026-01-09 15:21:00   348K 0.12 hours
3: pretest  warprrr_0.1.0.tar.gz 2026-01-09 15:10:00   1.0M 0.30 hours
4: recheck    mapsf_1.1.0.tar.gz 2026-01-09 15:07:00   1.4M 0.35 hours
5: waiting     ripc_0.3.2.tar.gz 2026-01-09 14:56:00   103K 0.54 hours
6: recheck rD3plot_1.1.45.tar.gz 2026-01-09 14:20:00   2.2M 1.14 hours
Five uploads in the last hour may suggest it is a 'you' problem.

Dirk
Roy Mendelssohn - NOAA Federal
# 
I can reach it from your work address but not from my home address.  When I do a traceroute from home I get blocked at the last step.

HTH,

-Roy
Hadley Wickham
# 
Hmmm, I tried from my phone and it worked once, but I tried again now and
it didn't work either. This is the traceroute I see, in case it means
anything to anyone.

traceroute to xmpalantir.wu.ac.at (137.208.57.16), 64 hops max, 40 byte
packets
 1  192.168.4.1 (192.168.4.1)  7.828 ms  3.684 ms  5.233 ms
 2  192.168.1.254 (192.168.1.254)  7.409 ms  5.343 ms  5.369 ms
 3  104-186-12-1.lightspeed.hstntx.sbcglobal.net (104.186.12.1)  6.222 ms
 6.569 ms  10.912 ms
 4  71.149.39.62 (71.149.39.62)  5.816 ms  6.046 ms  4.386 ms
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * 192.205.37.10 (192.205.37.10)  11.947 ms
10  dls-b24-link.ip.twelve99.net (62.115.139.131)  138.944 ms  140.363 ms
    dls-b23-link.ip.twelve99.net (62.115.138.65)  141.967 ms
11  dls-bb1-link.ip.twelve99.net (62.115.136.118)  12.237 ms  12.013 ms
 14.187 ms
12  * * nash-bb1-link.ip.twelve99.net (62.115.137.44)  100.600 ms
13  atl-bb1-link.ip.twelve99.net (62.115.137.54)  32.449 ms  32.397 ms
 31.204 ms
14  rest-bb1-link.ip.twelve99.net (62.115.138.70)  46.045 ms *  58.522 ms
15  prs-bb1-link.ip.twelve99.net (62.115.140.104)  120.740 ms  134.808 ms *
16  ffm-bb1-link.ip.twelve99.net (62.115.123.12)  126.600 ms  128.108 ms
 173.614 ms
17  win-bb1-link.ip.twelve99.net (62.115.137.203)  137.453 ms  140.338 ms
 138.001 ms
18  win-b7-link.ip.twelve99.net (62.115.137.103)  139.714 ms  142.909 ms
 140.607 ms
19  nextlayer-ic-392861.ip.twelve99-cust.net (62.115.205.175)  142.257 ms
 139.253 ms  139.711 ms
20  * * *
21  * * *
22  193.171.13.18 (193.171.13.18)  135.095 ms  139.585 ms  133.808 ms
23  vpn.wu-wien.ac.at (137.208.9.41)  135.997 ms  140.398 ms  138.908 ms

Hadley

On Fri, Jan 9, 2026 at 8:46?AM Roy Mendelssohn - NOAA Federal <
roy.mendelssohn at noaa.gov> wrote:

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Roy Mendelssohn - NOAA Federal
    

    

      
      #
    

  


  

      
clearly that should be from ?my work address ? IP.  I think it is real,  just appears to be selective,  such as something is blocking a range of IPs.  I have seen this when things like Akamai or Cloudfare or the like are in front of a server,  they decide that something should  be blocked.     I can provide traceroute  results if that would help.

-Roy

            

      
      
      
    

        

      
      
    

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Roy Mendelssohn - NOAA Federal
    

    

      
      #
    

  


  

      
My traceroute reaches 193.171.13.18 and then fails.

-Roy

            

      
      
      
    

        

      
      
    

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Uwe Ligges
    

    

      
      #
    

  


  

      
It seems some people tried to submit with devtools during the CRAN 
vacations while the submission webpage was deactivated.
Not sure what devtools does, but it seems some partial submission was 
possible that way (just incomplete) and that may have caused a pattern 
that lead to the IP block.

At least we had some reports about the above mentioned szenario. The 
sysadmin team tries to resolve this.
Perhaps simply send your IP to cran-sysadmin at R-project.org
for a quick solution.

Best,
Uwe

        
On 09.01.2026 16:32, Hadley Wickham wrote:

            

      
      
      
    

        

      
      
    

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      John C Nash
    

    

      
      #
    

  


  

      
Similar from here in Ottawa.

JN

        
On 2026-01-09 10:35, Roy Mendelssohn - NOAA Federal via R-package-devel wrote:

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    
1 day later

    

      
      

        


  

        

      Hadley Wickham
    

    

      
      #
    

  


  

      
Thanks for the fix!

Happy to chat about what devtools could do better here to avoid future
problems.

Hadley

On Fri, Jan 9, 2026 at 9:40?AM Uwe Ligges <ligges at statistik.tu-dortmund.de>
wrote:

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Uwe Ligges
    

    

      
      #
    

  


  

      
On 11.01.2026 15:19, Hadley Wickham wrote:

            

      
      
      
    

        
We try to find out why submissions got blocked. I guess devtools tried 
multiple times to open some webpage that was shut down and then the 
corresponding IP got auto blocked for too many connections within a time 
frame (which is why I get blocked by WU Vienna few times a year). We 
hope to get feedback from the sysadmins soon.


Best,
Uwe

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Dirk Eddelbuettel
    

    

      
      #
    

  


  

      
On 12 January 2026 at 01:08, Uwe Ligges wrote:

        
| We try to find out why submissions got blocked. I guess devtools tried 
| multiple times to open some webpage that was shut down and then the 
| corresponding IP got auto blocked for too many connections within a time 
| frame (which is why I get blocked by WU Vienna few times a year). We 
| hope to get feedback from the sysadmins soon.

Yep, for what it's worth, I also don't think it is 'the code' that drove it
(as I am using a derived piece) but likely rather repeated (?) usage. At some
point, I too got tired of the webform, and also got equally tired of the
[redacted] interaction enforced by devtools so I abstracted out a simpler
version of it leaning on the basic REST calls (that devtools so nicely
compiled). I put that in a script `crup.r` (CRan UPload script) that is part
of littler.  Been using it for a few months now for my uploads, and without
issues. It worked before the winter break and also worked afterwards for (so
far) three package uploads so seemingly I did not get blacklisted. YMMV.

Cheers, Dirk

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Roy Mendelssohn - NOAA Federal
    

    

      
      #
    

  


  

      
For what it is worth in my case as far as I can tell the behaviors of both devtools::submit_cran and the cran machine were quote reasonable,  even if it caused me a little pain.  The block Uwe describes sounds like fail2ban or the like,  and given the junk we see hitting our services  it is a reasonable thing to run.  I had the day wrong when I thought cran was back up.  devtools on submission said ti couldn?t connect,  It is not unreasonable as a submitter, thinking the machine was back up,  to wait a bit,  and  try again,  and maybe do so a few times throughout the day.  That is indeed what I did.  Then to be sure it wasn?t a devtools problem I went to the web page  and that is when it seemed to block me. 

So my point is everything to my mind behaved reasonably.  The only thing I could suggest,  and I have no idea of how much work this would entail, and I am not looking to make work for people,  is perhaps a banner on the webpage when the service is down,  and if possible have the server return to programs  like devtools an error that the service is down.

I can?t speak for why others were blocked,  but as I said this all seems reasonable.

Thanks,

-Roy

            

      
      
      
    

  
  


  


      

    

    
1 day later

    

      
      

        


  

        

      Simon Urbanek
    

    

      
      #
    

  


  

          

      
      
      
    

        
That?s the thing - there *was* a red banner that said no submissions are accepted so everyone using the official CRAN way was fine, it?s the back-door access by devtools that caused the problems. The issue is that once devtools got you blocked, it was too late so you couldn?t go back and see that you were not supposed to use it since your IP was already on the blacklist even for the official front-end. Clearly, devtools needs to be fixed to make sure it?s not submitting things blindly when it?s not supposed - probably with some help from the CRAN admin team to make sure there is a well-defiled path for this.

Cheers,
Simon

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Hadley Wickham
    

    

      
      #
    

  


  

          

      
      
      
    

        
Would it be possible for the form to be blocked as well as the submission
page? Typically web servers return a 404 or a 403 when a page isn't
available.

I can of course scrape the submission page, but now that the message is
gone, I don't know what to look for.

Hadley

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      jroseii@ m@iii@g oii gm@ii@com
    

    

      
      #
    

  


  

      
I believe it would be better to use the *503 status code. *It indicates
that the server is busy, overloaded, or down for maintenance

The HTTP Retry-After response header indicates how long the user agent
should wait before making a follow-up request. There are three main cases
this header is used:

In a 503 Service Unavailable response, this indicates how long the service
is expected to be unavailable.

*Jordi Rosell  *


El dt., 13 de gen. 2026, 14:32, Hadley Wickham <h.wickham at gmail.com> va
escriure:

            

      
      
      
    

        

      
      
    

        

  
  


  


      

    

    

      
      

        


  

        

      Henrik Bengtsson
    

    

      
      #
    

  


  

      
I checked the source code on submission page when it was still down; there
was an HTML <form> tag, but all <input> tags had been removed.

Submission via devtools went through and the CRAN incoming server responded
with the usual email asking the maintainer to confirm by going to the
"three-checkboxes" webpage. I didn't proceed from there.

Henrik

        
On Tue, Jan 13, 2026, 09:02 jroselln at gmail.com <jroselln at gmail.com> wrote: